4

I'm just switching a development project from SVN to git and it's the first time we'll be using branching of any kind. I'm wrapping my brain around the git-flow approach (based on this great article), but am stuck conceptualizing how to do one thing.

When we do a major version bump (say from 2 to 3) we still support version 2 for at least a year, including bug fixes and occasional new features. Would I create a new permanent branch for version 2 to apply those changes to? And if we get down the road developing for version 3 and decide that we want to add a new version 3 feature into version 2, is that possible, and how would you do it? Would I have to cherry-pick commits from the develop branch into the version-2 branch, or could I do an actual merge?

(I'm using Tower for my Git client)

CharlesB
  • 86,532
  • 28
  • 194
  • 218
Matt Dietsche
  • 578
  • 5
  • 17
  • see my answer here [Feature backporting in Git / Subversion](http://stackoverflow.com/questions/12132594/feature-backporting-in-git-subversion) – kan Sep 07 '12 at 12:50

1 Answers1

2

Yes, you would have a support branch and a development branch.

Any bugfixes on the support branch will very likely also be relevant for the development branch, so the support branch should regularly be merged into the development branch. Note that the more your development version diverges, the more merge conflicts will you encounter.

The other case, a feature from development being relevant for support, should be rather the exception than the rule (otherwise you would have developed it in support in the first place), so these commits should be cherry-picked. Merging the development branch into the support branch should not happen, because you very likely have a lot of untested, unfinished or experimental features in there which you don't want to release as a support patch.

Philipp
  • 67,764
  • 9
  • 118
  • 153
  • 4
    Just a follow-up one year later. We ended up creating "support", "dev", and "common" branches. This has allowed us to build features into the dev branch, while doing any refactoring in the common branch, and then merging common into both support and dev (and avoid cherry picking). We often only have to fix bugs in common because this approach has kept our code bases from diverging nearly as much. – Matt Dietsche Sep 05 '13 at 18:13