Помещение:

Допустим, ветвь репозитория master в git помечена как v4.0.

В какой-то момент (много лет назад) кто-то схватил клон тега v2.0 и внес в него кучу изменений, но не сохранил свою собственную ветку и даже не сохранил свой код под git .

Что еще хуже, самая большая проблема заключается в том, что он захватил фиксацию из ветки, которая на самом деле была дочерней для этого тега v2.0, и эта ветка теперь исчезла (должно быть, перебазирование, не уверен на 100%). Так что у меня действительно нет точного общего предка.

Что работает:

Различие между неотслеживаемым кодом и v2.0 может быть применено почти (с некоторыми Fuzz) до определенного момента в текущей истории коммитов (около нашей v2.7 tag), однако после v3.0 основные вещи изменились (каталоги перемещены, файлы переименованы и т. Д.), И эта разница, очевидно, перестает работать.

Таким образом, ветвь может быть создана из чего угодно v2.0..v2.7 в текущем репозитории, чтобы попытаться сохранить старый код так или иначе отслеживаемым.

Вопрос:

Каким будет правильный способ правильно объединить этот неотслеживаемый код в ветку, которая ближе к master?

Мне никогда не приходилось перебазировать что-либо, но если я правильно понимаю концепцию, я бы эффективно подтолкнул ветку masterк моей новой ветке, где Я применил diff (против v2.0 era), который затем я могу попытаться объединить обратно в ветку master.

Мой поток / процесс просто никогда не завершается успешно, когда коммиты v2.8..v3.0 начинают появляться, конфликты становятся довольно неуправляемыми, это как если бы коммиты были захвачены после исходного клона (некоторые патчи терпят неудачу, потому что они кажутся уже примененными), и это все портит (или, возможно, как я уже упоминал, мой первоначальный выбор для общего предка просто неправильно).

Если поиск правильного / ближайшего общего предка имеет первостепенное значение, существует ли git способ, чтобы сделать это? Все, о чем я могу думать, - это создать сценарий, который будет подсчитывать строки различий между старым кодом для каждого коммита в диапазоне и возвращать тот коммит, который дает наименьшее различие.

TL; DR

Существуют ли надлежащие процедуры / методы / инструменты / альтернативы для слияния разветвленного, неотслеживаемого, старого кода в недавнюю ветку ~ ish в git?.

Ответы (1)

• 100002 Затем я могу попытаться снова слиться с основной веткой.

Нет: a git checkout oldBranch; git rebase master будет воспроизводить коммиты из oldBranch поверх master.

Тогда обратное слияние с master будет тривиальным слиянием с перемоткой вперед.
Но перебазирование здесь не является практическим решением (слишком много коммитов для воспроизведения, слишком много конфликтов)

Существуют ли надлежащие процедуры / методы / инструменты / альтернативы для слияния разветвленного, неотслеживаемого, старого кода в недавнюю ветку ~ ish в git?.

Слияние (слияние master в вашу старую ветку) предпочтительнее для воспроизведения большого количества старых коммитов (что приведет к конфликтам при каждом воспроизведении фиксации).

В этом слиянии (сначала от master до вашей ветки) вы должны разрешить эти конфликты один раз (чтобы создать стабильную фиксацию слияния) изолированно в своей старой ветке.
Это будет непросто (не существует чудесного решения, позволяющего сделать старый код совместимым с более новым), но, по крайней мере, вы имеете дело с одной фиксацией (фиксацией слияния), которую нужно исправить.

Как только вы убедитесь, что ваше слияние работает, вы можете выполнить слияние обратно в master.

2022 WebDevInsider