Question

My use case is this:

1. tagged master v1.0
2. did some changes in master
3. live bug means I need to patch v1.0
4. I create a branch from the v1.0 commit make the changes and commit
5. I then tag the branch v1.0.1

I then want to merge the branch back into master. If I do this the v1.0.1 tag ends up being after the changes in master at point 2 (as you would expect).

I am guessing the answer is no, but is there anyway to merge the branch into the commit so that my 1.0.1 tag is attached to the commit after v1.0 and before the other changes in master. In effect ripling my change forward in time I suppose.

Or is the problem really my workflow, and I should have made my changes in 2 in a branch and only merged them to master when they were live.

Answer 1

A tag is immutable, so your issue is more about the order of commit.

What you can do is rebase master on top of branch v1.0.1:

git checkout master
git rebase v1.0.1

That way, the two new changes in master are replayed on top of V1.0.1.
If you hadn’t published master yet, a rebase is a convenient way to integrate fixes into your current branch.

See “git rebase vs git merge” for more.

---

As Graham points out in the comments, if your changes on master were already pushed, rebasing them can spell troubles for your colleagues having already pulled master.
See “Rebasing and what does one mean by rebasing pushed commits“.

In that case, it is bast to:

• make your changes on a ‘next‘ branch
• merge V1.0.1 in master (which then reflects at all times what is running in production)
• merge next in master when ready

(but if next needs the patch, then yes, you will be forced to apply it after your changes, because said changes have been already published, i.e. pushed to a remote repo)