Git: How to make sure fixes are contained in newer versions?

Question

Let's say I have both version 3 and 5 and 7 in production with different customers and meanwhile we're still developing features for version 8.

A bug is discovered in version 3, it is fixed and the version 3 customer(s) get a new version 3 (3.0.1 or whatever) with this hotfix.

Later a bug is discovered in version 5 by another customer and it too is fixed and a now we have to make a new hotfix release of version 5.

How do we make sure that this new version 5 (and indeed any future versions of version 5) contains all the fixes from previous versions?

Answer 1

Let say you have version_3, version_5, version_7 which represent as branches.

every fixed in version_3 should be merged by higher version.

eg

switch first into branch version_5

git checkout version_5

merge version_3 branch to version_5 branch

git merged version_5

then do this again in version_7 or higher version.

You can also use GIT GUI to be able to manage git repo easily by using SourceTree or GitExtensions

more info on git : https://www.atlassian.com/git/tutorials/git-merge

Answer 2

The answer to what you asked (how to "make sure" the bug is fixed) is to test every release, and not release new versions that exhibit known bugs.

What you're actually asking for is a process to ensure that the commit that fixed the bug in 3 will be included in any future releases of later versions. While this may not be a bad idea, it does not ensure that the bug is fixed in those releases; that is still the responsibility of testing. Even so, you at least would want to merge a new test case into every affected release version, and merging the fix from version 3 is a reasonable "first try" for fixing other versions, so some sort of merge pattern would be useful here.

There's really not a way to automate it, though. You can take steps so that anyone following your workflow would naturally pick up the changes. Anything that tries to be more thorough than that will likely involve a sweeping history rewrite - which will in turn impede efforts to support your existing install base.

So it comes down to this: You keep release branches so you can use them for subsequent releases in the same version line. (If your workflow resembles gitflow, this probably points to a master merge commit.) To start a hotfix you branch from the appropriate release branch. The hotfix contains both a test case that would fail without the fix and pass with it, and the fix as applied to that version. You merge that into every applicable release branch.

Answer 3

I agree with Mark Adelsberger's answer/comment, in that it's more a CI/testing/policy thing than a git specific thing. that said, I've had experience of a company that had a similar release strategy to yours, I'll try and briefly outline the way they did it:

If you had 3 released versions and one in develop:

v1
v2
v3
v4 (pre-release)
develop branch continues with changes for v4.

They had scenarios like:

Fix in v1 required only in v2 
    - Merge v1 -> v2
    - Fake merge v2 -> v3 (Take the only the state of the v3 branch so git doesn't report merge conflicts in future merges).
    - Fake merge v3 -> v4 (Take the only the state of the v4 branch so git doesn't report merge conflicts in future merges).

Fix in v1 required in all versions.
    - Merge v1 -> v2
    - Merge v2 -> v3
    - Massive code refactor in v3, fake merge into v4 (take v4 changes). 
    - Manually apply fix V4 changes.

Fix in v4 you want back ported to v2
    - Manually apply/cherry pick change into v2. 
    - Fake merge v2 -> v3 (Take the only the state of the v3 branch so git doesn't report merge conflicts in future merges).
    - Fake merge v3 -> v4 (Take the only the state of the v4 branch so git doesn't report merge conflicts in future merges).

It created a few headaches in that you end up doing a lot of testing on each branch anyway, because you'll still want to release tested software. The merging was set up to cascade automatically, but clearly that wasn't always possible, so you often resorted to manual resolution.

It also leads to some battling about the scope of bugs/features, because you're often reluctant to spend potentially quite a long time resolving merge conflicts when the code has changed drastically.

You will get situations like the second one, where a portion of the code has undergone a complete refactor/moved entirely, so the fix no longer applies, or needs to be applied in a different way. You then need to perform these "fake merges" where you're essentially performing a merge with no changes to prevent future merge conflicts when simple changes are applied.

It is doable, and is manageable, but the conclusion this company came to was very quickly to start reducing the number of supported versions in the wild; or only apply very simple/critical fixes.

More anecdotal than a useful answer, but too long for a comment =D