Блог

Главная - Вопросы по программированию - Проблема с рабочим процессом Git — множество конфликтов слияния, в которых файлы не были изменены

Проблема с рабочим процессом Git — множество конфликтов слияния, в которых файлы не были изменены

#git #azure-devops #merge-conflict-resolution

Вопрос:

Вот рабочий процесс, который используют наши команды:

  • main ветвь, в которую ветви функций объединены; это обрабатывается командой A
  • big-feature ветвь, которая используется командой B, которая была разветвлена от main
  • команда B будет иметь меньшие функциональные ветви от big-feature ; они используют регулярные ускоренные слияния, когда они втягивают свои функциональные ветви в big-feature

Проблема: время от времени команда B хочет получать последние изменения от main своих big-feature . Поэтому они делают следующее:

  • извлеките все изменения из источника и перенесите все изменения в их локальную main
  • создайте merge-with-main ветвь из big-feature
  • слиться main в merge-with-main

Теперь я ожидаю, что они должны получать конфликты только в файлах, в которые они внесли изменения, которые также были изменены main . Однако в настоящее время они получают более 250 конфликтов слияния, и большинство (если не все) из них находятся в файлах, которые они вообще не изменили. Глядя на конфликты в Visual Studio, становится ясно, что «их» файл-это, например, некоторая начальная версия файла с множеством NotImplementedException случаев, когда файл-заглушка был зафиксирован в main ветке, а «входящий» — это тот же файл с некоторой реализацией. Снова — тот же файл, явно не измененный командой B, но помеченный как конфликтный.

В настоящее время команда B вручную разрешает эти конфликты (обычно используя опцию «взять их»), но с более чем 250 файлами это действительно хлопотно. Что здесь происходит, и почему происходят эти конфликты, и что можно сделать, чтобы предотвратить / легко разрешить их?

Редактировать: я верю сквош-слияния используются на main может быть виновником, но насколько мне известно они должны только быть проблемой, если big-feature получает некоторые изменения из ветви компонента из группы — то git будет действительно «потерять» след ее, так как, когда команда совершает тогда источник филиала является, по сути, нет. НО команда B получает материал только напрямую main (помимо их собственных изменений, когда они, конечно, работают над своей собственной функцией), и у изменений в main должен быть источник, нет?

Опять же, слияния в сквош используются только тогда , когда команда А привлекает небольшую feature-branch main команду, и это делается системой PR Azure DevOps.

Комментарии:

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

2. @Pogrindis «Для начала это следует регулярно обновлять // объединять с main». Регулярные слияния с main — это именно то, что описано в вопросе как причина проблемы.

3. Слияние @IMSoP не является squash-merge

4. @Pogrindis В описании того, что они делают, просто говорится «объединить основное в слияние с основным». Слияния сквоша упоминаются только в отношении объединения других функций в основную. Возможно , они используют слияние сквоша в ветке «слияние с основным», и в этом случае это объяснило бы проблему, но на самом деле они этого не говорят.

5. @IMSoP ах, я думал о первом пункте, где, по — видимому, обнаруживаются конфликты-в этом случае будет ли fast-fwd, который команда A, вызывать некоторое несоответствие фиксации ?

Ответ №1:

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

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

OPs EDIT:
Оказалось, что команда B на самом деле не использовала регулярные слияния при обновлении своей bit-feature ветви с помощью кода из main и использовала сквош-слияния. Таким образом, они нарушили последний абзац этого ответа, вызвав всевозможные проблемы в дальнейшем.

Комментарии:

1. Согласитесь на регулярное слияние или перебазирование, если вам нужно сохранить все коммиты с main

2. Просто для ясности, в настоящее время в вопросе упоминается только слияние сквоша для других задач, входящих в основную. Шаг «объединить основное в слияние с основным» (а затем объединить его в большую функцию) на самом деле не указывает, какие параметры они используют. Но если они используют слияние сквоша для любого из них, вы правы, что это вызовет описанную проблему.

3. Похоже, это не то, что здесь происходит. Команда B не объединяет отдельные ветви функций из команды A в свою big-feature ветвь, а, скорее, они берут всю main ветвь. Так что… слияния сквоша НЕ ДОЛЖНЫ иметь эффекта, АФАИК.

4. @Shaamaan Согласно вашему собственному ответу, который был опубликован полчаса спустя, это именно то, что здесь происходит 🙂

5. @knittl Да — я не знаю почему, но я думал, что речь идет об отмене main , которая сама по себе не является проблемой. Я приму это.

Метки: ,