简体   繁体   中英

How to deal with major version branch in git

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)

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.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM