Git & ApartCI - Как проверить конфликты кода перед тем, как вызвать функциональную поломку? - PullRequest
Новая
       51

Git & ApartCI - Как проверить конфликты кода перед тем, как вызвать функциональную поломку?

0 голосов
/ 19 января 2019

После разработки на основе магистрали, показано ниже:

enter image description here

Предположим, есть две кратковременные ветви объектов (f1 и f2), созданные из master (транк). Для реализации в этом сценарии файлы исходного кода, используемые для этих ветвей перекрываются .

Предположим, существует один конвейер CI / CD для master (транк), который запускается при изменении кода.

Один возможный конфликт кода является функциональным, f1 может удалить или изменить существующий исходный код, который используется f2 .... Это , а не конфликт VCS .

Разработчик1 выполнил git commit на f1 (в ноутбуке) во время t и пока push

Developer2 выполнил git commit на f2 (в ноутбуке) во время t+24 и еще push

Насколько я понимаю, ниже приведен сценарий в файле истории коммита ноутбука перед нажатием:

enter image description here С учетом приведенного выше сценария, f1 может получить слияние с master, что является простым быстрым слиянием . Итак, master и f1 будут указывать на 156b4bf коммит-снимок после этого слияния, как показано ниже:

enter image description here Конвейер CI / CD запускается при успешном слиянии без конфликтов

Но когда f2 фиксация происходит через 24 часа, Git выполнит 3-стороннее слияние , используя 3 снимка (156b4bf, 96f5b29 и c435356), как показано ниже:

enter image description here Конвейер CI / CD снова запускается, , если слияние успешно. Насколько я понимаю, Git должен блокировать трехстороннее слияние из-за функционального конфликта.

1) Используя Git, обнаруживает ли перемотка вперед / 3-way слияние функциональный конфликт?

2) Если да, есть ли другие конфликтные сценарии, не связанные с VCS, на которые ApartCI обращаются? что Git не может ... если да, то как?

Примечание: нет плана для использования Рабочий процесс Gitflow

1 Ответ

0 голосов
/ 20 января 2019

A чисто функциональный конфликт - это конфликт, в котором 2 конфликтующих изменения не затрагивают одни и те же файлы:

  • f1 изменяет прототип функции (скажем, в файле S1 ) и все ее использования (скажем, в файлах S2 и S3 )
  • f2 добавляет использование новой функции в другом файле, в котором функция ранее не использовалась (скажем, в файле S4 ), используя оригинальный прототип, так как он еще не видит f1 изменения

Каждое отдельное изменение может пройти проверки, но при объединении в одну ветвь код не будет работать, так как вызов, добавленный в S4 , не будет соответствовать обновленному прототипу из S1 .

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

Только проверки, выполненные инструментом CI / CD, могут обнаружить такой чисто функциональный конфликт путем обнаружения несоответствия. В зависимости от используемого языка это может быть либо ошибка сборки / компиляции, либо ошибка тестирования / выполнения / выполнения.

Если 2 изменения вызывают конфликт слияния (трехсторонний или нет), это означает, что конфликт является VCS, а не чисто функциональным, и да, он будет обнаружен инструментами на основе git и / или git, поэтому это должно быть решено до того, как слияние будет разрешено (выполнение инструмента CI / CD не будет необходимым для его обнаружения)

На ваш второй вопрос ApartCI обнаружит конфликт любого типа:

  • если это конфликт VCS, 2 изменения перекрываются (то есть они оба касаются хотя бы одного общего исходного файла), поэтому они не будут объединены вместе для одновременной проверки. Это означает, что они никогда не окажутся в первичном комплекте вместе. Один из них будет зафиксирован и в конечном итоге получит baseline проекта. Как только это произойдет, другое изменение не будет исправлено в следующей попытке проверки и будет отклонено.
  • если это чисто функциональный конфликт, 2 изменения не пересекаются, поэтому они могут оказаться или не оказаться в одном пакете.
    • если они не находятся в одном и том же пакете, поток событий будет почти таким же, как для конфликта VCS
    • если они находятся в одном и том же пакете, проверка пакета не удастся, и после действий разбиения пакета они в конечном итоге окажутся в другом пакете, и снова последует тот же поток событий, что и для конфликта VCS
...