1

I’m trying to use Git to manage different versions of a product. There are a few ways I could do this. I’m familiar with the concept of having a “master” branch, and labelling different points along that master branch to constitute named “Versions” of the solution. E.g., at some point in time I might decide that the current build represents the “RP_2012” build of my product. Later on, after some more features have been added, there might be a “RP_2013” version, etc.

It occurs to me that even though development may be finished on a particular ‘version’, bug fixes may still need to be rolled out. E.g., say I’m working in Azure, and each customer has their own version of the solution rather than a multi-tenancy arrangement (because that way I get to be able to offer them newer versions of the product if they want to pay to upgrade, and they get to stay with older versions of the product that they are comfortable with until they are ready to upgrade rather than having new features imposed upon them). I have a script that uses a combination of TeamCity, FluentMigrator, etc, to be able to take the version a particular customer has and upgrade it at will whilst preserving their existing data. So, whilst any new features that are being added to the product will be getting created on their own branch then merged into the Head of master for release in some future version, there also needs to be scope for doing bug fixes that may be applied to any/all of the versions of the product that are currently being used/supported.

If I use the labelled version approach and a single “master” branch as discussed above, rolling out such bug fixes might not be possible. If I instead give each version its own branch, would it be possible to carry out bug fixes in a separate branch that derives from an ancestor of each of the “version” branches, and later merge that one branch into several distinct, version-specific branches? Or is there perhaps some clever way to use Rebase so that if I have a bug fix that will affect versions 10, 11 & 12, say, and those ‘versions’ are just labelled points along the master branch, can I just branch off from the point labelled “version 10” in master, and somehow rebase master to be based on the fixes that will be done in said bug fixing branch, thereby ensuring versions 10 and upwards all benefit from the fixes a given branch addresses? At the same time, of course, any new features would be done by branching off from and merging back into the Head of master.

I hope my question and underlying intent is clear enough. In essence, I would like to know if it’s best to keep different versions of a given product in one master branch. And, if so, how best to implement bug fixes that will be able to be rolled into each version when/if required. This may involve merging a single branch into several discrete descendent branches. Or it may involve rebasing a single branch that all of the versions live in. Or perhaps you guys know of some cleverer way.

Thanks in advance for any suggestions.

Deleted
  • 900
  • 5
  • 9

2 Answers2

2

I would suggest using "git flow" for this. It's an extension to git to handle the use case you are describing, with one master and develop branch, separate release branches and separate feature branches. See this and this blog post for a detailed description of the branching model used.

You should be very careful about using rebase for the purposes you are describing. Rebase will rewrite the version history, which will make it very confusing and difficult if there are commits from people with "different" version histories.

Steinar
  • 5,860
  • 1
  • 25
  • 23
  • Ideal, thanks. That looks like exactly the type of thing I need. I'll have a look through your links. – Deleted Mar 24 '13 at 14:05
  • I've had a read through, and your links answer my question exactly. This is a brand new account, so I can't give reputation yet, but I've marked your response as the answer to my question, Steinar. Thanks a lot for your help, and for yours too Tarek. – Deleted Mar 24 '13 at 17:15
  • Thanks Rachel, hope you'll have good experiences with git flow. I've been using it for the better part of a year and like it a lot. I've converted all the git repositories I work with to this model. One thing I'd like to mention, which confused me a bit in the beginning, is that git flow will only change your local repository. If you need the branches on the remote repository, you'll need to push the branch manually to the remote repo. – Steinar Mar 24 '13 at 17:42
  • Thanks for that. I did wonder about that when the blog post referred to in your second link stated that "Feature branches typically exist in developer repos only, not in origin". The way I've worked in the past, developers produce features and then before those features are merged back into the main build another developer in the team does a peer review to sanity check the work that's been done. It's only a slight variation from the approach suggested to Push a developer's local Repo to Origin to allow a second developer to take a look at their work. I appreciate you mentioning it. – Deleted Mar 24 '13 at 18:07
  • Exactly. I guess the reason is that git supports so many different distribution models, but still I tend to go for having one "master" remote repository. With this model, you get these kinds of situation all the time. E.g. when several people work together on a feature, they will proabably need to share that branch somehow. It is also the same with release branches, which are created locally on the machine where you perform the release. If you have a "master" remote repo, you'll need to push it there manually. – Steinar Mar 24 '13 at 18:23
  • 1
    Not sure why this question was closed as "not being constructive". It's one of the few SO questions I've seen that resulted in a consensus on a single answer from all of the participants to the (short) discussion: this answer being it. I think you might be over-controlling discussion a little here, guys. There being more than one possible answer to a question doesn't make it a "debate", or "unconstructive". A consensus on the best way forward was reached only a few hours after this question was posted, and a full eight days before you closed the thread! I wouldn't call that a "debate". – Deleted Apr 23 '13 at 00:59
1

I don't think there's an objective way to define what is best here.

Personally, I always go with the 1-branch-per-release model. Especially so if you have multiple clients. Sometimes even a client would ask for a custom feature, so you branch off of their branch for a minor release, and so on.

In your case, assuming you go with the multi-branch model, and you have a bug fix that you want to apply to some branches, you could cherry-pick that fix/commit into whatever branches that need it.

Also, check this question, the asker provides a script for committing to multiple branches at the same time. Using cherry-pick for that matter.

Community
  • 1
  • 1
Mohamed Tarek
  • 385
  • 3
  • 11
  • Thanks for your answer. I'm tending towards a COTS model rather than doing any bespoke builds, so the scenario of supporting custom features doesn't apply in my case. Thanks for the Cherry Picking idea. That's a way I can go if I end up with different branches per version. The script in the question you've linked to looks like it'll do the necessary if I decide to go that way. – Deleted Mar 24 '13 at 14:10
  • Quite welcome. Tiny note here, minor version releases could be branching off major release branches. It doesn't exactly have to be bespoke builds. – Mohamed Tarek Mar 27 '13 at 07:53