The default git merge is usually all you need, but if you have to deep deeper, you’ll find that git merge command has very weird looking and confusing options.<\/p>\n
I created\u00a0https:\/\/github.com\/ikriv\/merges repository that shows the result of applying different variants of git merge command.<\/p>\n
For starters,\u00a0 The “-s” variant creates a commit that merges current branch and “xyz”, but ignores\u00a0all\u00a0<\/em>changes from xyz, so the resulting content would be identical to the current branch. This is useful for getting rid of unwanted branches when force-pushes and deletes are disabled. The “-X” variant only ignores changes from xyz that cause a conflict<\/em>. Changes from xyz that do not cause a conflict\u00a0will\u00a0be included\u00a0<\/em>in the end result.<\/p>\n Similarly, git has\u00a0 Git annoyingly lacks\u00a0 “Theirs” merge strategy that ignores the current branch can be simulated by creating a temporary branch and using “ours” strategy on it, but why do we need to jump through those hoops?<\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":"git merge -s ours xyz<\/code>\u00a0is not the same as\u00a0git merge -X ours xyz<\/code>. The first uses merge\u00a0strategy<\/em> called “ours”, and the second uses default ‘recursive’ merge strategy, but with “ours” option<\/em>.\u00a0Creating two entities named “ours” that do similar, but subtly different things is the epitome of \u00a0bad interface design.<\/p>\ngit merge -X theirs xyz<\/code>, which will merge current branch and xyz, but will ignore changes from the current branch that cause a conflict and will takes those from xyz instead.<\/p>\ngit merge -s theirs xyz<\/code>, which would merge current branch with xyz and make the result identical to xyz. This would be very<\/em> useful to simulate force pushes, but alas. I naively tried to use\u00a0git merge -X theirs xyz<\/code>\u00a0instead and got into hot water.<\/p>\n