Стратегия Git Merge - наш вариант использования

Question

Я прочитал книгу Pro Git и наткнулся на следующий вариант использования нашей стратегии слияния :

Это часто может быть полезно, чтобы обмануть Git, думая, что ветвь уже слита при последующем слиянии. Например, допустим, что вы разветвили ветку релиза и выполнили некоторую работу над ней, чтобы в какой-то момент вам захотелось вернуться обратно в вашу основную ветку. Тем временем некоторые исправления на master необходимо перенести в ветку релизов. Вы можете объединить ветку исправления ошибок с веткой выпуска, а также merge -s ours ту же ветку с вашей основной веткой (даже если исправление уже существует), поэтому при последующем объединении ветки выпуска исправления ошибок не возникают.

Может кто-нибудь объяснить мне, как в этом случае возникает возможный конфликт между основной веткой и ветвями выпуска? И зачем мне фальсифицировать, что я уже слил ветку исправления ошибок в мастер?

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

Answer 1

Проза немного сложна для распаковки, и я думаю, что пункт полезной нагрузки:

хотя исправление уже есть

действительно не должно быть в скобках.

Описанная ситуация - это исправление ошибки, которое уже на master, а также существует в некоторой ветви исправлений, которая не была объединена с master. Возможно, это было выбрано как исправление, «слишком важное», чтобы поддерживать вменяемую историю?

Как бы то ни было, в этом параграфе делается попытка проиллюстрировать один тип ситуации, в которой вы бы хотели слияние -s ours, и теперь, когда я думаю об этом, я думаю, что это очень хорошая иллюстрация одного такого: запутанный, вероятно, результат некоторые бездумные слияния вишни и тыквы, вы просто пытаетесь понять, как исправить запись, не прерывая всю работу, которая произошла с тех пор, потому что теперь у вас есть ложь:

  B1..B2         bugfix
 /
*...B'...        master
 \
  `--...         release

Так что на самом деле здесь произошло, какой-то бездумный придурок, вероятно, я, сквош-слил bugfix в master, потому что это было проще всего или что-то в этом роде. Вы столкнулись с этим и едва удержались от того, чтобы позвонить мне и подать мне выбор мыслей, приходящих вам в голову, потому что, хотя я ужасно оскорблял слияние сквоша здесь, эй, есть простое решение:

git checkout release; git merge bugfix
git checkout master; git merge -s ours bugfix

создание графика истории, вероятно, лучше всего нарисовать как

  ,--...*...o     release
 /         /
*--B1--B2-'       bugfix
 \         \
  `...B'...-Bx    master

Что не совсем верно, но так близко к праву, что вам не придется форсировать историю, которую я должен был сделать. Сообщение коммита для Bx, вероятно, должно выглядеть следующим образом: "- наше слияние с ошибкой, записывающей слияние сквоша в B '" или что-то подобное.

Теперь и люди, и машины могут легко увидеть, что произошло, и причины объединения историй: последующее слияние с release до master не будет пытаться применить изменения в B1 и B2, потому что оно видит, что они были объединены.