Modify old release on Github for pushing out a patch

Question

Say I have various tags / releases, 1.0, 1.0.1, 1.0.2, 1.0.3. Master branch is currently the bleeding edge, in preparation for 1.1.0.

I now realize that I need to push a small patch, 1.0.4.

What's the best way to make the patch based off of 1.0.3, push it to github, tag it as 1.0.4, but then still keep master branch at the bleeding edge and preparation for 1.1.0?

EDIT: Repository in question (note, it's actually v1.0.5 -> v1.0.6): https://github.com/brashrebel/render

Answer 1

I would say you have two possibilities: one leaving 1.0.4 as a dangling commit in its own branch, and another one rebasing all of your later commits on top of that new branch, and then discarding it.

The first would mean:

$ git checkout v1.0.3
$ git checkout -b patch-for-1.0.4
# ... edit files ...
$ git commit -a -m 'Patch for 1.0.4'
$ git tag v1.0.4

After this, your tag v1.0.4 is not in the master branch, but it is findable in the repo and you can make a release out of it. You only have to be careful not to remove the branch patch-for-1.0.4.

The second would mean do the aforementioned, and then continue to:

$ git checkout master
$ git rebase patch-for-1.0.4
# ... solve conflicts ...
$ git branch -d patch-for-1.0.4

This assumes that all commits working from 1.0.3 towards 1.1.0 have been done on master. If you expect many conflicts, you may want to test this first on a branch made right off master, or do an --interactive rebase.

This second alternative is cleaner, and you can remove the patch-for-v1.0.4 branch; but it entails rebasing old commits on top of newer ones, and this is something that not everyone feels comfortable doing, specially if you are working in a team.

EDIT:

This is your starting situation:

A -------- B - C - D  ( ... will become v1.1.0)
(v1.0.3)

The first snippet creates a patch and leaves it as a dangling commit in its own branch:

A -------- B - C - D
\
 --- E
     (v1.0.4)

If you do a merge at this point, you will get:

A --------- B - C - D --------- E
(v1.0.3)            (v1.1.0)    (v1.0.4)

In order to avoid that E is put on top of the B - C - D commits, do a rebase:

A --------- E ------- B' - C' - D'
(v.1.0.3)  (v1.0.4)             (v1.1.0)

Note that this changes commits B - C - D to B' - C' - D', which have the same contents (except for conflict fixes), but different hashes, because they are now on top of E, not A. This may break the master branch of other people on your team, or their feature branches, but leaves things in their logical order.

Answer 2

You check out the commit you want to base your patch on. You do what's necessary, create your commits, tag the result and push. In order to get them into your mainline you can either cherry-pick those commits or merge the branch back.

Now, it might be a bit awkward if the new tag is not on a branch. I certainly have never seen a branch that is only reachable by a tag. So my personal recommendation would be to merge the branch back.

To be a bit more concrete:

$ git checkout -b v1.0.5_fixes v1.0.5    # create a bugfix branch
# ... do some work ...
# ... make commits ...
$ git tag v1.0.6
$ git checkout master
$ git merge v1.0.5_fixes     # merge back, solve merge conflicts if any
$ git branch -d v1.0.5_fixes # delete the branch, it's not needed anymore