Слияние хаоса - объединение двух не связанных между собой ветвей, каждая с основными изменениями

Здесь ситуация:

существует ведущая ветвь M
в какой-то момент появилась ветвь функции F из M. Это должно было стать основной ветвью для функции, и все другие разработчики, работающие над этой функцией, должны были разветвляться из этой ветки или работать непосредственно с этой веткой.
в какой-то момент из M была создана ветвь F1. Часть разработчиков разработчиков создала собственную ветку и начала работать над частью этой функции. Но они забыли использовать F, вместо этого они использовали M. И никто не знал об этом (включая меня).

Большинство разработчиков, работающих с этой функцией, использовали F. Они несколько раз перегружали F на M несколько раз (каждый раз при перемотке вперед). Все идет нормально. Однако несколько разработчиков, использующих их F1, а также несколько раз переустанавливаются на М.

Сегодня был день слияния хозяев. Поэтому разработчики с F1 перешли на F - они сообщили о некоторых проблемах слияния; но через несколько часов они сообщили об этом и F есть все.

Теперь, я, я хотел объединить F в M и официально завершить работу над F. К моему supprise, он не мог быть объединен на github автоматически. Поэтому я сделал git fetch и начал перезагружать F на M. И хаос начался, конфликты. Все они появляются в файлах, которые мы даже не касались при работе над F. Я сдался после 20-30 разрешений конфликтов и git rebase -continue.

Теперь, когда я понял (после чата с этими разработчиками), что у них есть F1, созданный с М, а не с F Кажется, я знаю, что вызывает конфликты. Это потому, что изменения для M теперь применяются к F во второй раз? Правильно ли мое предположение? Я не уверен. Но я уверен, что не знаю, как решить эту ситуацию. Я не могу своевременно объединить F в M из-за бесконечного количества конфликтов в файлах, которые мы даже не касались при работе над F.

Ответ 1

Если вы объедините свой F в M, а не перегружаете F на M, вы получите не более одного разрешения конфликта, а не одно за фиксацию, как кажется, вы испытываете.

Прежде чем вы это сделаете... Мне кажется, что ваши разработчики считают, что ни F, ни F1 не коснулись файлов, которые конфликтуют, потому что конфликт доказывает, что эти файлы были изменены как в F-ветки, так и в главном. Если вы не должны были менять эти файлы, посмотрите историю этих файлов с журналом git и посмотрите, когда они были изменены в F. Там есть хорошая вероятность, что кто-то внес некоторые непреднамеренные изменения в ветку, возможно, во время rebase. Отмените/отмените эти непреднамеренные изменения, и ваш конфликт может стать намного менее сложным.

git log -p origin/master..F -- path/to/unexpected_conflicting_file

Наконец, если только ваши команды не имеют только 1 человека кодирования в филиале функции, я бы серьезно подумал о переходе от рабочего процесса перезаписи к рабочему процессу слияния. Каждый раз, когда вы переписываете разделяемую ветку (через rebase или иначе), она заставляет всех других разработчиков делиться веткой с ASAP reset или переустанавливать свою ветвь на перезаписанную/сгруппированную историю, которую перетасовал рестайзер. Если кто-то забывает и тянет без переустановки на переустановленную ветку, у вас есть две версии истории, которые часто конфликтуют друг с другом. Это подверженный ошибкам и ненужный шаг, которого можно избежать, просто сменив его.