git releases management

Question

I couldn't find anything what is the "right" approach to manage the releases using git. Say, I have master, release-1, release-2 and release-3 branches. Release 1 is already released and I do only bugfixing and released versions tagging on it. Release 2 is going to be released soon and I develop mostly on this branch while on 3 I develop things which will be needed in the further future.

1. When I add some feature on release-2 and it should go to 3 as well, but not to 1, should I:

   • merge release-2 to master and cherry-pick feature related commit to release-3?
   • cherry-pick feature related commit to master and than cherry-pick it to release-3?
   • sth else?

2. When I need to changes sth in all the versions, should I do it on master and cherry-pick it to all the branches?

3. Should I keep master up to date with the newest(release-3 branch) or rather developer on release-3 and merge to the master just before I will need release-4 branch?

4. When I fix sth on release-1 or release-2, should I merge or cherry-pick it to master or rather?

I'm not quite sure when should I cherry-pick, when should I merge and if the flow of the code between the branches it right.

Answer 1

See the following posts on Junio C Hamano (git maintainer) blog:

• Completing a merge
• Never merging back (about branches forked with intention of not merging back)
• Resolving conflicts/dependencies between topic branches early
• Fun with remote branches (1)
• Fun with remote branches (2)

Take also look at gitworkflows manual page.

Answer 2

What you are asking is a typically a merge workflow problem: what to merge from where to where.

But you also need to remember that in a DVCS, a merge will also be influence by publication considerations (are those branches pushed to local repositories, or public ones)

"master" branch in particular is the one visible by default when someone clone your repo, meaning it should reference what you consider most useful to that user/developer. (since other branches are not referenced locally by default)

---

1/ When I add some feature on release-2 and it should go to 3 as well, but not to 1

You can indeed merge r2 to master, after having made a number of commits to r2 in order to achieve the necessary evolutions. That way, only a limited number of commits are visible in master, avoiding "commit cluttering".
For r3 however, you can cherry pick what you need from r2, if r3 is being pushed and published. Otherwise, you could rebase r3 on r2. See "git workflow and rebase vs merge" question

2/ When I need to changes sth in all the versions, should I do it on master and cherry-pick it to all the branches?

You should do it on r2, and then merge on master and r1 and r3. That way, only one commit is added to those branches.

3/ Should I keep master up to date with the newest(release-3 branch) or rather developer on release-3 and merge to the master just before I will need release-4 branch?

It depends on what you want your other colleague to see when they clone the repo.
But from 1/, I gather master is representing r2 (current development) and not r3 (future, long-term refactoring)

4/ When I fix sth on release-1 or release-2, should I merge or cherry-pick it to master or rather?

• r1: cherry-pick: not all what you are fixing on r1 is meant to be merged to current development.
  Actually, I would rather cheery-pick r1 fixed on r2, make sure everything work there, and then merge on master.
• r2: merge. If master represents r2, a simple merge is enough.

Answer 3

I would do:

1) Merge r2 to master and then master to r3 (r3 should be able to accept all changes to master)

2) Commit to r1, merge to r2, merge r2 to master and then merge master to r3

3) Maybe you should use master instead of r3, and only develop on branch off r3 when the release is under preparation and merge up all changes here to master (which will be the next version). Or use "master" and "next" branch as Linux.

4) Merge to master

I think merging is cleaner than cherry-picking and think you should only cherry-pick when you need to backport a feature or bugfix to an older branch that you did not expect when the commit was made (else commit on the oldest branch/release you want the code on).