Зачем использовать "git merge -s ours"?

Question

Я понимаю, что "наша" стратегия слияния (услышать кавычки вокруг merge ?) На самом деле не использует коммиты из другой ветви.

«Наша» стратегия иногда упоминается как «сохранение истории другого». Но она записывает эту историю как «примененную». Weird. Есть ли случаи, когда я хочу такого поведения?

В качестве альтернативы, вы также можете импортировать другую ветку и оставить ее историю там, где она принадлежит.

Обратите внимание, что я спрашиваю о стратегии "-s ours", а не о опции "-X ours" для "-s recursive" (которая отличается тем, что применяет те коммиты, которые не конфликтуют).

Answer 1

Одно из применений - это «пропустить» коммит, сделанный в ветке обслуживания, которая не предназначена для возврата в вашу основную ветку / ветку разработки. См. Этот предыдущий вопрос для примера: git - пропуск определенных коммитов при слиянии

Answer 2

Другая причина в том, что у вас есть ветвь, которая очень не синхронизирована с вашей активной веткой, и вы хотите обновить старую ветвь активной, но возможные конфликты слияния не позволяют легко сделать это с помощью обычного слияния.

Например, мой вариант использования был:

У вас есть ветка master и dev, и по какой-то причине вы не обновляли ветку master в течение нескольких недель, и ваша попытка слить ветку dev в master теперь приводит к конфликтам слияния. Что вы можете сделать, это переписать вашу основную ветку с текущим состоянием вашей ветви разработки, поэтому приведите их в синхронизацию.

В этом случае вы можете сделать следующее, используя шаги, описанные другим пользователем SO в другом ответе SO здесь . Но, пожалуйста, смотрите мое предупреждение ниже .

git checkout dev
git merge -s ours master
git checkout master
git merge dev

Стоит короткое примечание: в конце мой мастер был в курсе моего dev, но dev показал 4 коммита, которые должны быть переданы на пульт, что странно. Там должно быть 0, чтобы нажать, так как я просто хотел обновить мастер. Тем не менее, код выглядел нормально. Стоит отметить, что я никогда раньше не использовал git merge -s ours, поэтому я не на 100% использую его.

Я также нашел другой ответ, используя ours, который может быть полезен людям: https://stackoverflow.com/a/13307342/339803

Answer 3

Я использую это псевдо-слияние в дополнительной ветке, используемой для отслеживания других веток, в том числе и заброшенных.Эта дополнительная ветвь фактически имеет только один файл (называемый branches-list), который содержит текстовый список активных и неактивных ветвей, но в важных точках (в основном это точки ветвления и «конец ветви», либо слияние, либооставьте) ветки разработки объединены (с "-sas") с этой веткой.

Вот недавний скриншот нашего проекта :

Таким образом, я наконец-то разветвил elo-test от мастера, а затем от этого я разветвил stroke-transform-example для моего вопроса здесь (и ответ - это должны быть две разные коммиты, хотя).В каждой такой точке ветвления, и что более важно, в каждой точке, когда ветвь заканчивается без слияния с какой-либо другой ветвью (что произойдет с stroke-transform-example при следующей очистке), теперь я объединяю эту ветвь с -s oursв мета-ветку branches.

Затем я могу позже удалить ветки, которые больше не используются, не теряя их историю, поэтому вывод git branch -a всегда довольно мал.Если я когда-нибудь захочу оглянуться назад на то, что сделал тогда, я легко их найду.

(я думаю, что это не то, для чего эта опция сделана, но она работает довольно хорошо.)

Answer 4

Одно использование для этого - подготовка к другому слиянию.

Допустим, у вас есть некоторые последующие изменения, которые вы хотите объединить с новой вышестоящей версией, но новая вышестоящая версия не является потомком git по сравнению со старой вышестоящей версией (возможно, потому что старая вышестоящая версия была стабильной ветвью, которая разошлась из транка, может быть потому, что вышестоящие версии были фактически результатами инструмента импорта).

То, что вы можете сделать, это.

1. Проверьте новую версию апстрима.
2. "psuedomerge" старая версия для апстрима.
3. Объединить новую версию ниже по течению.

Таким образом, ваши локальные изменения будут объединены, но git не будет пытаться объединить старые вышестоящие изменения, поскольку считает, что они уже объединены.

Answer 5

Другое использование - это альтернатива принудительному толчку, который не вызывает изменений без ускоренной перемотки для других.

Например, вы хотите отменить входящий (глупый) коммит, но вы неЯ не хочу делать git push -f, потому что тогда вы потратите следующие полчаса на то, чтобы помочь своему клиенту восстановиться после этого, и вы захотите более короткую альтернативу

git checkout -b temp remote/origin
git revert HEAD
git push temp:origin
git checkout master
git merge origin/master

, поэтому вы просто делаете

git merge -s ours origin/master