0

How does one deal with the case of former releases that are not subject to be merged back to the main development branch ('master' by default)?

Could you point to some documentation that describes that?

Current question is using Git alone (not gitflow).

Bludzee
  • 2,380
  • 5
  • 29
  • 38
  • possible duplicate of [Advice on multiple release lines and git-flow, for git non-gurus](http://stackoverflow.com/questions/18220663/advice-on-multiple-release-lines-and-git-flow-for-git-non-gurus) – nwinkler Jun 30 '15 at 21:15
  • It's worth noting that a lot of git users think git-flow puts a lot of unnecessary constraints. – o11c Jul 01 '15 at 01:40
  • If current post is "primarily opinion-based", why aren't those flagged the same? [Advice on multiple release lines and git-flow, for git non-gurus](http://stackoverflow.com/questions/18220663/advice-on-multiple-release-lines-and-git-flow-for-git-non-gurus) [Following git-flow how should you handle a hotfix of an earlier release?](http://stackoverflow.com/questions/16386323/following-git-flow-how-should-you-handle-a-hotfix-of-an-earlier-release/16386527#16386527) – Bludzee Jul 01 '15 at 08:32

1 Answers1

1

Just leave that release in its own branch without merging to master and/or develop. Merging is not mandatory. If any subsequent development or fix should be added to that release you can use that release branch.

Dalija Prasnikar
  • 24,159
  • 30
  • 74
  • 140
  • Thanks! And suppose there is a few man-months of work to do on this old release, shall I consider this old release branch like a kind of 'master' branch like in the model and create a 'develop' branch dedicated to this old release and so on? (I hope you follow me) – Bludzee Jun 30 '15 at 20:59
  • Exactly. Use that release branch as sort of master and branch off as many new dedicated branches as you need. – Dalija Prasnikar Jun 30 '15 at 21:02