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

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.