Pros and cons of branching when fixing old code

Question

Sometimes I discover that a commit I made two months ago had a bug. So I write a fix for the bug, but then I must choose one these ways of committing it:

1. I can commit the fix directly onto the main up-to-date branch (the trunk).

2. I can use a branch at the point of the original buggy commit, and commit the fix immediately after it. Then I merge the branch into the trunk.

   (This approach is sometimes recommended if the bug was made on an existing "feature branch".)

3. (Wildcard) I could use --fixup to mark the association, but I will be unable to rebase because invariably the history has already been shared.

I can see some pros and cons with each approach, but I am wondering if experienced users have more to share than I can imagine.

In short my question is: Do any organisations find approach #2 sufficiently useful that they adopt it as standard?

(Outside of the case of maintaining an older release, where it would probably be the obvious choice to fix on the old release branch and then merge into the later releases and the trunk, when possible.)

Answer 1

My understanding is that in your scenario, the feature has been completed, the branch merged, and a release made?

If so, then there is no reason or benefit to re-write history. This is a bug fix that is not part of your feature change. So, simply a new branch to fix your bug. Don't associate it in the repository directly with the original feature branch - you can use whatever bug tracking and project planning tools you have to make that association.

And of course don't just edit and push master branch, unless you are following a company process where that is considered OK (perhaps some kind of hot fix, where you are pair programming or reviewing on screen before commit).

Your original feature and bug fix are separate events in the project's history. Treat them explicitly as such, there is little or no benefit to altering that for some concern of neatness by association. After all, nearly all the bugs in the application have this exact history - they will have been introduced as part of some planned change, and fixed later when they were discovered.

Answer 2

Op here, not wanting to pollute the question with my current thoughts.

Here are the pros that I can conceive for forking (supporting approach number 2):

• We have associated the fix with the original commit, because it comes immediately after it. It may be easier in future to see this association.

• I can now, if I wish, go back to any point in the intermediate history, and merge in this branch to just fix the bug and nothing else. (This could be useful to remove the complications of this bug when bisecting, albeit with caveats.)

• If I don't fork, then I tend to leave the ID of the original buggy commit in the message of the fix commit. So there is at least an explicit association, but surely it is better to make an implicit association using git's own history.

• This approach won't always be trivial: sometimes it may result in a merge conflict.

And here are some cons for forking (supporting approach number 1 or 3):

• Looking at the git history graph, we would now see a long arc reaching from the original commit all the way up to the present, when it gets merged into the trunk. If we use this approach often, our history will become very wide with branches! But perhaps this should be considered not a problem, but a feature.

• Forking won't directly help to avoid this bug when bisecting. Although we do have a branch which fixed the original bug without all the intermediate commits, it doesn't actually enter the trunk until the present.

Finally some thoughts on approach number 3, although it is probably a non-starter:

• Using --fixup is implicit, in that git understands the association. It is clear and somewhat standardised.

• However I do not think this was the original purpose of --fixup.

• One might argue it could cause confusion in future: rebase --autosquash might one day try to move that commit back in the history. But I suspect that is a non-concern, since nobody should try to rebase back into shared history, as it could cause plenty of other problems.