Why would one use "git merge
I understand that the "ours" merge strategy (hear the quotes around merge?) actually does not use any commits from the other branch.
The "ours" strategy is sometimes mentioned as "keeping the other's history". But it records that history as "applied". Weird. Are there cases where I do want this behaviour?
As an alternative, you could just as well import the other branch and let its history there, where it belongs.
Note that I am asking about the "-s ours" strategy, not the "-X ours" option to "-s recursive" (which is different in that it applies those commits that don't conflict).
One use is to "skip" a commit made on a maintenance branch that isn't intended to go back into your main/trunk branch of development. See this previous question for an example: git - skipping specific commits when merging
I'm using this pseudo-merge in an additional branch used to track the other branches, including abandoned ones. This additional branch has in fact only one file (called branches-list ), which contains a text list of the active and inactive branches, but at the important points (mostly branch-points and "end-of-branch", either merge or abandon) the development branches are merged (with "-s ours") to this branch.
Here a recent screenshot of our project:
Thus, I lastly branched elo-test from master, and then from this I branched stroke-transform-example for my question here (and the answer - this should have been two different commits, though). At each such branch-point, and more importantly, at each point when a branch ends without it being merged to some other branch (which will happen to stroke-transform-example when I next clean up), I now merge this branch with -s ours to the meta-branch branches .
Then I can later delete the not-used-anymore branches without losing their history, so the output of git branch -a is always quite small. If I then ever want to look back at what I did then, I can easily find them.
(I think this is not really what this option is made for, but it works quite nice.)
Another reason is when you have a branch that is very out of sync with your active branch, and you wish to update the old one with the active one, but possible merge conflicts prevent this from being done easily with a normal merge.
For example, my use case was:
You have a master and dev branch, and for some reason, you have not updated your master branch in weeks, and your attempting to merge your dev branch into master now results in merge conflicts. What you may want to do is overwrite your master branch with the current state of your dev branch, so bring them both in sync.
What you can do in this case is as follows, using steps which have outlined by another SO user in another SO answer here. But please see my warning note below .
git checkout dev
git merge -s ours master
git checkout master
git merge dev
Worth a quick note: At the end of it, my master was up to date with my dev, but dev showed 4 commits to be pushed to the remote, which is strange. There should be 0 to push, as I just wanted to update master. Nevertheless, the code seemed fine. Just worth noting, as I had never used git merge -s ours myself before this so im not 100% on its usage.
I also found another answer using ours which could be useful to people: https://stackoverflow.com/a/13307342/339803
上一篇: 修复git合并分支到master的冲突
下一篇: 为什么会用“git merge”