We are now in the process of switching from svn to git (after a year spent on convincing people, yay!) in my company.
So far, this is all for the better but there is one little thing that we currently have in our workflow that I can't find a good equivalent too.
Currently, all our developers work in master. Once every quarter, we branch master into X.x branch, which will later on become our latest release. This means that our svn repo looks like this:
We don't really use tags.
Once in a while, there is an urgent bug fix that is discovered.
The current way for us to do it is:
- Fix it in master
- SVN merge the relevant range of commits back into the relevant branches (Maybe our latest release, maybe more).
We are in the space industry, so our branches are long lived and the customer upgrade process is rather long, which is why we have worked like that so far.
Now, how would be a good equivalent in git?
So far, I have tried to fix the bug in a branch spawned from master, and then merge this branch back in master and in 4.3 (for example). Thing is, the hotfix branch contains the master history, and all the commits between master and 4.3 get merged as well, which we don't want to.
Things I could think of so far:
- I have looked at the very successful Git Workflow method, and their solution is to fix the bug in the release branch and merge it back instead of the other way around. This could work in our case, but would be rather cumbersome because it would require us to already know the oldest branch we want to fix the bug in before actually fixing the bug.
- Another solution is to fix in master, and then cherry pick the commits (as we do for the svn merge today). The annoying thing here is that in this case we lose history of what has been merged back where, since cherry picks look like new commits and we lose the relationship.
So what is the "good" way to do it? Should we fix commits in history, or cherry pick and manually keep track of what has been merged, or even something else?
If have little production experience with git, so I am sure I may have missed something.