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
