13

Automated CI tool merges fixes from release to master. But some commits from release branch should be ignored.

Let's consider the following example:

Release branch contains two fixes: fix-1 should be ignored and fix-2 should be merged to master.

base ----------- merge-fix-2 -        master
  \                  /            
   fix-1 --- fix-2 ---                release

With this configuration merge of fix-2 also includes fix-1 changes.

To avoid this I need empty merge-commit (ignore-fix-1), just for notify Git that fix-1 has been already merged and these changes should be ignored in upcoming merges:

base -- ignore-fix-1 -- merge-fix-2 --  master
  \       /             /            
   fix-1 ----- fix-2 ----               release

The question is: how to do that ignore-fix-1 empty commit?

Max Farsikov
  • 2,451
  • 19
  • 25

2 Answers2

17

You can pass -s ours to git merge to use the "ours" merge strategy, which does exactly what you want: performs a "merge" by completely ignoring the incoming branch.

That said, this is a surprising thing to do to your history, to say the least. I assume you have a compelling reason not to want a hotfix in master, but if this sort of thing happens frequently, you might want to consider a different approach, e.g.:

  1. Split release into stable (for fix-2) and production (for fix-1), then frequently merge stable into both master and production.
  2. Cherry-pick release fixes, rather than merging them.
Eevee
  • 47,412
  • 11
  • 95
  • 127
  • 2
    Thanks, `git merge -s ours` does the trick! And thank you for advice, I will think about stable-release branch. Cherry picking as for me is a good technique, but not for the automated tool. – Max Farsikov Aug 09 '18 at 20:46
0

There's several ways to accomplish this. Probably the simplest is to do the merge normally and then git revert <commit ID of fix-1>.

base ----------- merge-release - revert-fix-1 [master]
  \             /            
   fix-1 - fix-2 [release]

This has the added benefit of not re-adding fix-1 when release is merged into master again.

The larger question is why your release branch has commits in it which are not to be brought back into master. Normally commits directly to a release branch are emergency hot fixes. If you need to do this only very occasionally, like for a particularly sloppy hot fix, then git revert is the way to go. If you plan to do this regularly, this workflow is unmaintainable and you should ask a question about the workflow itself.

Schwern
  • 153,029
  • 25
  • 195
  • 336
  • 1
    Thank you for answering but for automated tool this approach does not fit well. But I agree with you, what I described is not best way to do CI – Max Farsikov Aug 09 '18 at 20:52
  • @MaxFarsikov You have to manually decide that a fix is not to be included anyway. Seems to me you can allow the automatic merge to happen as normal and then manually apply the revert after. If you want to automate the whole process you can flag a commit which is to be reverted with a special tag and teach CI to do the revert after the merge. And yes, having exceptions like this does not fit automation. – Schwern Aug 09 '18 at 21:37