git – skipping specific commits when merging

If you want to merge most but not all of the commits on branch “maint” to “master”, for instance, you can do this. It requires some work—- as mentioned above, the usual use case is to merge everything from a branch— but sometimes it happens that you made a change to a release version that shouldn’t be integrated back (maybe that code’s been superceded in master already), so how do you represent that? Here goes…

So let’s suppose maint has had 5 changes applied, and one of those (maint~3) is not to be merged back into master, although all the others should be. You do this in three stages: actually merge everything before that one, tell git to mark maint~3 as merged even when it isn’t, and then merge the rest. The magic is:

bash <master>$ git merge maint~4
bash <master>$ git merge -s ours maint~3
bash <master>$ git merge maint

The first command merges everything before your troublesome maint commit onto master. The default merge log message will explain you’re merging “branch ‘maint’ (early part)”.

The second command merges the troublesome maint~3 commit, but the “-s ours” option tells git to use a special “merge strategy” which, in fact, works by simply keeping the tree you are merging into and ignoring the commit(s) you are merging completely. But it does still make a new merge commit with HEAD and maint~3 as the parents, so the revision graph now says that maint~3 is merged. So in fact you probably want to use the -m option to git merge as well, to explain that that maint~3 commit is actually being ignored!

The final command simply merges the rest of maint (maint~2..maint) into master so that you’re all synced up again.

Leave a Comment