Recommended practises for using git when collaborating using MATLAB/Simulink

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.

Answer 1

[Luca Ferro]

I just did exactly the same thing with my team earlier this year and this is what i've learnt so far:

• 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.

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

[Thomas]

Hi Luca. Thank you very much for this sound advice. It is definitely something we will discuss and attempt to implement.

When collaborating on Simulink diagrams, do you also create dummy functions for the MATLAB function blocks, in order to ensure tracking by your version control system? Since changes within Simulink result in binary changes. I'm specifcally referring to the suggestions presented within 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 .

[Luca Ferro]

we don't. I actually dislike that solution quite a bit since it creates some very obscure code. I much rather prefer to have decent communication and update them manually if needed. We also have a huge custom library of functions to refer to and that gets (or should get) updated regurarly. Maybe this approach is not the best for very large teams though. We work in basically 12 on the same simulinks and those after careful review are shared to other departments for a total of 60~ish people.