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.
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?
When I need to changes sth in all the versions, should I do it on master and cherry-pick it to all the branches?
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?
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
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.