Git & amp; ApartCI - Как проверить конфликты кода перед вызовом функционального сбоя?
Вместо того, чтобы иметь компоненты, ответственные за их имена, я бы создал класс NameGenerator, которому был предоставлен корень и (необязательно) начальный номер, который предоставляет NextName:
public class NameGenerator {
private int _next;
private readonly string _nameRoot;
public NameGenerator(string nameRoot) : this (nameRoot, 0)
{}
public Namegenerator(string nameRoot, int firstNumber)
{
_next = firstNumber;
_nameRoot = nameRoot;
}
public string NextName()
{
return String.Format("{0}_{1}", _nameRoot,_next++);
}
}
Ваш Generator класс должен теперь иметь набор этих объектов (до вас, нужно ли инициализировать их с нетерпением или лениво), а ваш класс Component должен иметь конструктор, принимающий имена, которые выкидывает NameGenerator.
public class Component_A{
public string name {get;private set;}
public Component_A(string name){
this.name = name;
}
}
1 ответ
чисто функциональный конфликт - это конфликт, в котором 2 конфликтующих изменения не затрагивают одни и те же файлы:
- f1 изменяет прототип функции ( скажем, в файле S1 ) и все его использования (скажем, в файлах S2 и S3 )
- [ 1123] f2 добавляет использование новой функции в другом файле, в котором функция ранее не использовалась (скажем, в файле S4 ), используя оригинальный прототип, так как он пока не видит изменения f1
Каждое отдельное изменение может пройти проверки, но при объединении в одну ветвь код не будет работать, так как добавленный вызов в S4 не будет соответствовать обновленному прототипу из S1 .
В этом случае оба слияния выполняются с ускоренной перемоткой вперед, и git не может обнаружить конфликт - не будет фактических слияний файлов при трехстороннем слиянии, поскольку наборы изменений не затрагивают одни и те же файлы. Таким образом, конфликт также не будет обнаружен инструментами на основе git, анализирующими слияние, например, gerrit.
Только проверки, выполненные инструментом CI / CD, могут обнаружить такой чисто функциональный конфликт путем обнаружения несоответствия. В зависимости от используемого языка это может быть либо ошибка сборки / компиляции, либо ошибка тестирования / выполнения / выполнения.
Если 2 изменения вызывают конфликт слияния (трехсторонний или нет), это означает, что конфликт является VCS, а не чисто функциональным, и да, он будет обнаружен инструментами на основе git и / или git, поэтому к нему нужно будет обратиться до того, как слияние будет разрешено (выполнение инструмента CI / CD не будет необходимо для его обнаружения)
На ваш второй вопрос ApartCI обнаружит любой вид конфликта:
- если это конфликт VCS, 2 изменения перекрываются (т.е. они оба касаются хотя бы одного общего исходного файла), поэтому они не будут связаны вместе для одновременной проверки. Это означает, что они никогда не окажутся в первичном пучке вместе. Один из них будет зафиксирован и в конечном итоге окажется в базовом сценарии проекта . Как только это произойдет, другое изменение не будет исправлено в следующей попытке проверки и будет отклонено.
- Если это чисто функциональный конфликт, 2 изменения не пересекаются, поэтому они могут оказаться или не оказаться в одном пакете.
- , если они не находятся в одном и том же пакете, поток событий будет в значительной степени таким же, как и в случае конфликта VCS
- , если они находятся в одном и том же пакете, проверка пакета не удастся и после действия расщепления связки они в конечном итоге окажутся в другой связке, и снова будет следовать тот же поток событий, что и для конфликта VCS