Workflow Matlab with Git

55 views (last 30 days)
Sargondjani
Sargondjani on 6 Jan 2022
Edited: Bogdan Bodnarescu on 14 Jun 2022
I am new to Git. I mainly use Git to publish releases of Matlab packages. The packages consists of a core with some functions and folders. In addition to that I have support folders and files (with examples, documentation and some test scripts).
Before using git I would work on a new release by copying only the core, and some test scripts to a new folder. I would then update the core, and the test scripts until everything works. And then I would update the support folders and files such that they are consistent with the core, and publish the release.
My questions is: how would you organize this work flow with Git?
Intuitively, I would bascially keep doing the same: make a new branch say "update_main", and copy only the core and the test scripts into that branch. Make that branch work, and then update and add the support files to that branch. And finally merge (or simply overwrite) the "main" with the "update_main" and publish the new release.
This procedure ensures that the core and support files are consistent within each branch, which seems kind of important to me.
However, my suggested approach implies that I would hardly use Git for the main process, since I could just as well make a new directory, and build the new release there. Git would then only help with merging code (for example when I work on two updates at the same time).
One disadvantage of using branches in this case would be that they are not directly visible in directories, so I am not even sure using Git branches has that many benefits compared my old approach where I would build a new release in a new directory.
Does this make sense? Does anybody have any thoughts or advice on this?
  2 Comments
Ilya Gurin
Ilya Gurin on 6 Jan 2022
First, welcome to Git! It's my all-time favorite productivity tool.
I'm not sure what exactly you're trying to do with your "packages." How many packages are we talking about? Do they have a common "core", with other elements that are unique to each package?
Sargondjani
Sargondjani on 6 Jan 2022
@Ilya Gurin yeah, so far I love Git too! Just trying to get the hang of efficient workflows...
What I call a "package" is basically a toolbox (core) plus support files. So we may basically assume one package = one toolbox = one repository. Everything is unique for each toolbox (no overlap), so we can discuss as if there is only one toolbox.

Sign in to comment.

Accepted Answer

Benjamin Kraus
Benjamin Kraus on 7 Jan 2022
Edited: Benjamin Kraus on 7 Jan 2022
Welcome to the world of version control. Git is an amazing and powerful tool, but it can take some getting used to.
I would suggest you take a step back from the specifics of your project (or even MATLAB) and just start with some Git (or even version control) basics.
The first basic is that if you find yourself copying an entire folder for a release, you are probably not using Git to it's full advantage. If you are a developer working alone on a project, you can still heavily benefit from Git without ever branching or copying your folder. I assume you've done this already, but start by creating a Git respository in your code directory, then checking in all the files. My suggestion would be to start with the latest release, check that code into Git, then immediately tag the current state (using git tag). By tagging this state, you can always restore your current working directory back to that state using git checkout). There is no need to manually make a copy of the folder. As long as you've committed any changes into Git, you can always use git checkout to switch to any other version of your files, all within the same directory.
As you work, whenever you complete a small chunk of work (it is up to you to decide what "small" and "chunk of work" mean), check that into Git. Every time you call "git commit" the code you've submitted is given a unique label, allowing you to restore that state. Git tag is just a way to give a friendly name (rather than a long and complicated automatically generated name). Once you are ready for a new release, use git tag again to name that specific version of the code.
The only reason to have two separate folders with to different copies of your code is if you want to be able to run two versions of your code at the same time (or perhaps open them side-by-side, but there are ways to do that in git as well). However, once your code is in Git, you shouldn't be copy/pasting an entire folder any more. You should be using "git clone", "git push", and "git pull" (and "git fetch") to create a clone of one directory into another directory. This isn't required, but this will work best if you pick a hosting service (like GitHub or GitLab), and then each copy of your code can synchronize with that server.
Once you've got those basics down, there are a few reasons to branch, such as:
  1. You want to work on two independent features. You can create a branch for each feature, and then when the feature is done you can merge it back into the main branch.
  2. You want to apply bug fixes to a past release, without incorporating all the new features into the past release. You create a branch based on the release (you can create a new branch from a git tag), and apply the fix to just that branch.
  3. You are working in a team.
When you get to that point, you may want to look at some online articles and tutorials regarding different branching models for Git. There are a ton of different articles (and opinions) on this topic. I did some very very quick Google searching using search terms like "git branching models" or "git branching strategies" (and I am not endorcing any of these specific models), but to give you some specific examples of what I mean, here are some links:
This isn't required, but my personal recommendation would be to learn the command line versions of all of the above first, get a good solid understanding of how Git works and what it means to commit, branch, tag, merge, rebase, push, and pull. Once you've done that, you can start leveraging the tools built-in to MATLAB to make your life easier, but it will be easier to understand those tools if you've learned the command line versions.
I hope that helps get you started!
  15 Comments
Sargondjani
Sargondjani on 12 Jan 2022
Yeah, its good you mention this testing thing. I also automated my testing a lot more. It helps a lot
Bogdan Bodnarescu
Bogdan Bodnarescu on 14 Jun 2022
Edited: Bogdan Bodnarescu on 14 Jun 2022
Is there a similar topic for workflow Simulink with Git?
Until now I couldn't find a way to merge Simulink models that are modified on different branches, also merging the generated code files and all the other .mat files and other type of files that Embedded Coder generates is a nightmare.
For a simple branch merge it takes me around 1 day of work to solve all the conflicts and even after so much work I can still find bugs introduced by automatically merging of the simulink models.
Is there any way to tell git not to do anything with some specific file types, I saw that if I configure a Matlab Project then a .gitattribute file will be generated, but still the automatic merge will be triggered by using meld or modelmerge from Matlab so this doesn't seem to work either?
Should I make a new topic for Simulink and Git only?

Sign in to comment.

More Answers (0)

Categories

Find more on Source Control Integration in Help Center and File Exchange

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!