Это должно быть хорошо понятной проблемой, но я, похоже, не могу найти соответствующую информацию.
TL; DR: git Отображение между кодом двух ветвей кажется нарушенным из-за грязной истории ветвей.
Настройка:
Я поддерживаю «удлинительная» вилка. Т.е.:
- У меня есть
fork репозиторий, который является копией origin. (И у меня есть локальный репозиторий, который различает пульты fork и origin.) - Форк содержит пользовательское расширение для проекта. Я фиксирую свои изменения на
fork/master. - Всякий раз, когда есть обновление
origin/master, я объединяю его в fork/master. (То есть, я напрямую извлекаю и объединяю origin/master в локальный репозиторий, а pu sh в fork/master.) - Со временем 'fork / master' иногда значительно отличается от master, но позже сходится обратно опять же, поэтому большая часть кода все еще находится в соотношении «1-1».
Проблема:
Таким образом, «расходящиеся» коммиты накапливаются на fork/master (сотни из них). В последнее время у меня возникают (все больше и больше) проблемы с разрешением конфликтов:
Git слияние приводит к множеству конфликтов, причина которых неясна.
Git объединение часто автоматически разрешает конфликты неправильно. На практике это означает, что после слияния я часто нахожу «случайные» фрагменты кода, вставленные или удаленные в «случайных» местах. Эти изменения совершенно неверны, но были применены без необходимости их пересмотра.
(Отображение кода между разделами кода полностью нарушено, что, очевидно, является причиной проблемы, но делает невозможным ручное рассмотрение автоматически примененных изменений в коммите слияния.)
Я предполагаю, что причиной является трехстороннее слияние, которое пытается учесть всю историю коммитов веток с момента первого дивергентного коммита.
Попытка решения:
Я попытался «перебазировать» форк в один сдавленный коммит поверх origin/master и объединить эту ветку в fork/master:
git checkout -b master_rebased master
git reset --soft origin/master
git commit
git checkout master
git merge master_rebased`
Таким образом, fork/master теперь фактически две альтернативные истории. Я утверждал, что git всегда будет автоматически вычислять «кратчайший» путь расхождения (полностью содержащий весь набор изменений), прежде чем вычислять слияния или статистику расхождения, но нет - git по-прежнему утверждает, что моя ветвь на сотню коммитов впереди origin/master.
Конечно, я могу просто выбросить старый fork/master и заменить его перебазированным мастером, но это звучит как очень неясный способ решения проблемы, что, вероятно, означает, что я что-то упустил.
Резюме:
Итак, вопросы в основном таковы:
1) Какой самый чистый способ примирить разветвленную ветвь?
2) Что является правильным git рабочий процесс для поддержки длительного расширения вилки?
3) В качестве альтернативы: что мне не хватает?