- Establish ownership early: Establish clear and somewhat strict bondaries of what is one person responsability and what's not. Basically, divide the project in sections and assign each section to a person of reference. This will help with both conflicts handling and organization purposes. If everyone is allowed to touch everything it will be a big mess in no time. Maybe use branch permissions as well.
- Matlab GUI is great but: Use the guy as much as possible because it really semplifies things. The conflict viewer is your most powerful ally for sure. But, someone has to have enough knowledge to do the manual dirty work through bash (or matlab command window connected to bash). The gui is quite restrictive with the actions than can be performed.
- Choose a branching method: Git is the best tool ever for coding, it needs some adaptations for model base engineering (and binary files). Branch ownership, permissions, branch types, ... all need some bending to adapt it to a different workflow. It's very case specific.
- Experiment: create a sandbox environment to test things out and get people used to it. Better safe than sorry, especially if it is the first time approahing git as a whole.
- Use projects: Easy to visualize using the gui, easy to use and come with some pretty nice automatisms like startup scripts, shutdowns scripts. Also if you go for a multiple repositories it's quite versatile in the referencing.
- Keep consistency: Be as consistent as possible with namings, interfaces, etc. Create a glossary so that everyone is using the same conventions. All of these small annoyaces waste a lot of time. The glossary once settled will make your life easier.
- Code generation: a git best practice is not to track files that can be generated at anytime. Said so, do as you wish. I'm not familiar with the issue of matlab function blocks (beacuse of the structure we gave the project) but i think that with good communication and meaninful commit messages it can be addressed somewhate effectively.
Recommended practises for using git when collaborating using MATLAB/Simulink
33 vues (au cours des 30 derniers jours)
We're a professional team who are collaborating on a larger MATLAB/Simulink project, where the resulting Simulink model is exported to C/C++ code.
I'm unable to find clear guidelines on how to most efficiently use a version control system such as Git alongside large and complicated Simulink diagrams.
Our diagram consists of both Subsystems (https://se.mathworks.com/help/releases/R2022a/simulink/slref/subsystem.html) and Model references (https://se.mathworks.com/help/releases/R2022a/simulink/slref/model.html), with MATLAB function blocks within them.
In 2020 and 2021, it seems that the official advice is to create "dummy" function calls from within the MATLAB function blocks, in order to allow properly version control of the MATLAB code (see https://se.mathworks.com/matlabcentral/answers/748477-how-do-i-manage-the-contents-of-matlab-function-blocks-via-source-control and https://se.mathworks.com/matlabcentral/answers/1454589-how-do-i-separate-the-contents-of-my-matlab-function-blocks-from-my-slx-file-for-easier-version-cont?s_tid=answers_rc1-2_p2_MLT). As technology rapidly evolves, we're unsure whether this approach is still what is officially recommended by Mathworks.
This article (https://se.mathworks.com/help/matlab/matlab_prog/use-source-control-with-projects.html) primarily concerns version control, but not collaboration.
As result, the following questions have arisen:
- Are there any official guidelines on how to collaborate on Simulink diagrams as a team, whilst using a version control systems such as Git?
- Does extracting the MATLAB code from the MATLAB function blocks create performance issues when exporting the Simulink models to C/C++ code?
Thank you very much in advance for your time and assistance.
Luca Ferro le 13 Mar 2023
Modifié(e) : Luca Ferro le 13 Mar 2023
I just did exactly the same thing with my team earlier this year and this is what i've learnt so far:
Here is a link to a best practices article i liked when i first started: Commit Often, Perfect Later, Publish Once—Git Best Practices (sethrobertson.github.io)
Note: for some reason mathworks recommended us to keep the compression type of the .slx files to 'none'.
Note2: we used to use SVN instead of Git. It worked great, i still don't have an opinion on the transition since too little time has passed