Перезапись и толкание ветки Git

Question

При слиянии моих изменений с ведущим ведущим я часто обнаруживаю, что выполняю следующее:

git checkout somefeature
git checkout -b integration
git rebase master # resolving conflicts along the way
git checkout somefeature
git merge integration # or rebase, doesn't matter in this example

Я часто обнаруживаю, что объединение ветви интеграции с моей ветвью функций приводит к некоторым конфликтам.Первый вопрос, который у меня возникает: «Почему это происходит, если моя ветвь интеграции является потомком какой-то особенной модели, и я уже разрешил конфликты с ведущим устройством верхнего уровня?»

Если вам интересно, почему я используюНачнем с того, что ветка интеграции состоит в том, чтобы предотвратить загрязнение моей текущей ветви половинным неудачным слиянием.

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

git push origin somefeature
! [rejected]        somefeature -> somefeature (non-fast forward)

Так что теперь мне нужно удалить удаленную ветку и повторно отправить свои изменения.Это не может быть оптимальным способом сделать это, поэтому я задаюсь вопросом: «Каков наилучший способ перезаписать ветку и перенести изменения в удаленную ветку?»

Answer 1

Проблема вызвана тем, что git rebase генерирует новую серию коммитов, которые не происходят от ветви somefeature, затем, когда вы пытаетесь объединить их обратно в somefeature, разрешение конфликта, выполненное во время ребазинга, не 'т применить.Если бы вам нужно было просто выполнить слияние вместо rebase, тогда это сработало бы, поскольку коммит слияния будет спускаться с ветви somefeature.

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

Answer 2

Вы можете использовать git merge -s recursive -Xtheirs, который будет автоматически разрешать конфликты в пользу ветви интеграции.Тем не менее, это все равно делает слияние и может плохо воспроизводиться с перемещающимися файлами и т. Д.

Однако, поскольку ваша ветвь перемещается, у вас есть причина хотеть сохранить ее историю.Чтобы получить идеальное поведение, которое вы хотите, вы можете использовать «нашу» стратегию в ветви интеграции.

git checkout somefeature
git checkout -b integration
git rebase master # resolving conflicts along the way
git merge -s ours somefeature # mark integration as superseding the somefeature branch
git checkout somefeature
git merge integration # this is now a fast-forward, no conflicts

Answer 3

Ваш первый бит операций очень странный. Вы делаете копию Somefeature. Вы опровергаете это против хозяина. Затем вы возвращаетесь к этой функции и объединяете ее с перебазированным эквивлантом. Это не способ делать вещи.

Не усложняй вещи. Если вы хотите, чтобы ветвь функции начиналась где-то еще (например, с последней версией), просто перебазируйте ее.

Затем нажмите его с помощью --force (или -f). Скажите кому-нибудь еще, кто использовал эту ветку функций, что они должны получить изменения и откорректировать все, что у них было локально, что они еще не отправили.

Слияние лучше в том случае, если над ним работают другие.

Надеюсь, это поможет.

Answer 4

Вы можете убедиться, что ваше окончательное слияние перезапишет целевую ветвь с помощью драйвера слияния:
См. " Можно ли, например, сказать git pull перезаписать вместо слияния? ".

Идея состоит в том, чтобы иметь пользовательский драйвер слияния со скриптом "keepTheir" .