Ответ 1
Как говорится в man-странице, -s ours
полностью игнорирует содержимое другой ветки. Это должно быть достаточно очевидным: независимо от того, что в другой ветке, дерево, прикрепленное к фиксации слияния, идентично дереву в объявлении HEAD
до слияния.
Что -X ours
делает более тонким: он использует "нашу" версию изменения только тогда, когда есть конфликт.
Здесь относительно простой пример.
Предположим, что вы находитесь на ветке br1
, и вы просите слить в ветке br2
. Мы сделаем их очень простыми, с фиксацией B
(начало базы слияния для обеих ветвей), имеющее одно единственное commit K
на ветке br1
, и одно единственное commit L
на ветке br2
:
... - B - K <-- HEAD=br1
\
L <-- br2
Кроме того, разница от B
до K
состоит только из одного элемента:
- изменить (уже существующий) файл
f1
: заменить первую строкуdog
наcat
Между тем разница от B
до L
состоит из:
- изменить файл
f1
: заменить первую строкуdog
наpoodle
- изменить файл
f2
: заменить последнюю строкуelephant
наrhinoceros
Когда вы объединяете их без стратегии или параметров, в файле f1
(разные изменения в тех же строках) будет конфликт, но не в f2
(слияние будет принимать изменения в commit L
, чтобы файл f2
изменился).
Если вы используете:
git merge -s ours br2
команда merge будет использовать "нашу" версию файла f1
(dog
становится cat
), а также наша версия файла f2
(elephant
не изменена).
Если вы используете:
git merge -s recursive -X ours
команда merge найдет конфликт в файле f1
и решит его в пользу нашей версии - это то же самое, что и раньше, - но конфликт в файле f2
отсутствует, поэтому git будет использовать свои версия f2
(elephant
становится rhinoceros
).
(Этот простой пример не показывает, что произойдет, если есть два разных изменения в разных областях в f1
или f2
.Если f1
достаточно длинный, и есть изменение в фиксации L
дальше, чем "первая строка файла", слияние может забрать это изменение, так как оно не будет конфликтовать с изменением dog
-to- cat
.)