Git strategy to backport bugfixes into older branches (cherry-pick vs. merge)

Question

We work as follows in our team:

• we have only a master branch in our GitHub repo, it\'s not stable - thinks get pushed there each day; for stable r

Answer 1

In open source projects that I've worked on, the consensus seems to be that fixes should land on master first, be tested there, and only then be back-ported to older releases. You can see this in how the Linux kernel does stable releases, for example: Developers submit patches for mainline but nominate them for inclusion in stable as well.

When cherry-picking in this situation, you probably want to use the -x flag:

When recording the commit, append a line that says "(cherry picked from commit ...)" to the original commit message in order to indicate which commit this change was cherry-picked from. This is done only for cherry picks without conflicts. ... [If] you are cherry-picking between two publicly visible branches (e.g. backporting a fix to a maintenance branch for an older release from a development branch), adding this information can be useful.

Answer 2

Your strategy 2, first fixing the bug on the prior release branch, e.g. v1.2.4 and then merging that change to your development trunk, is suggested by gitworkflows(7):

Rule: Topic branches

Make a side branch for every topic (feature, bugfix, …). Fork it off at the oldest integration branch that you will eventually want to merge it into. [emphasis added]

Many things can then be done very naturally:

To get the feature/bugfix into an integration branch, simply merge it. If the topic has evolved further in the meantime, merge again. (Note that you do not necessarily have to merge it to the oldest integration branch first. For example, you can first merge a bugfix to next, give it some testing time, and merge to maint when you know it is stable.)

One reason that this tends to work well is that in my experience, stuff gets added more frequently than it gets removed, so by making the change in the older branch, you avoid depending on any new functions etc. which may be available in the development trunk.

However you have to think about which branch you are targeting for the fix when you make the change, instead of just doing it on master and then deciding where to merge it.

Both strategies are viable and there are benefits to each.