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 alre

Answer 1

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.