Menu
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).
795
git merge -s ours. The ours strategy is simple: it discards all changes from the other branch. This leaves the content on your branch unchanged, and when you next merge from the other branch, Git will only consider changes made from this point forward.
Recursive is the default merge strategy when pulling or merging one branch. Additionally this can detect and handle merges involving renames, but currently cannot make use of detected copies. This is the default merge strategy when pulling or merging one branch.
Merging is a common practice for developers using version control systems. Whether branches are created for testing, bug fixes, or other reasons, merging commits changes to another location. To be more specific, merging takes the contents of a source branch and integrates them with a target branch.
While merging is definitely the easiest and most common way to integrate changes, it's not the only one: "Rebase" is an alternative means of integration.
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
180
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
