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

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

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

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

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

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

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

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

• если это конфликт VCS, 2 изменения перекрываются (т. е. они оба касаются как минимум одного общего исходного файла), поэтому они не будут объединены вместе для одновременной проверки. Это означает, что они никогда не попадут в основной пакет. Один из них будет зафиксирован и первым попадет в базовый план проекта. Как только это произойдет, другое изменение не будет исправлено при следующей попытке проверки и будет отклонено.
• if it's a purely functional conflict the 2 changes are not overlapping, so they may or may not end up in the same bundle.
  • if they are not in the same bundle the flow of events will be pretty much the same as that for a VCS conflict
  • если они находятся в одном пакете, проверка пакета завершится ошибкой и после действий по разделению пакетов в конечном итоге они окажутся в другом пакете, и снова последует тот же поток событий, что и для конфликта VCS.