Там, где я работаю, у нас есть стратегия ветвления, которая в основном гласит, что есть самый верхний main (назовите его main, trunk, что угодно), который всегда стабилен, затем группа проектов, затем проект, оба с их соответствующими main ветви (взяты с одного уровня «вверх», ближе к самому верхнему основному). На уровне проекта дальнейшее ветвление для определенных функций может или не может быть сделано, в зависимости от сложности выполняемой работы. (Например, не нужно создавать ветку объектов для исправления нескольких опечаток в тексте пользовательского интерфейса.) В целом, это работает хорошо. Мы также осуществляем контроль исходного кода на уровне базы данных как часть более крупного дерева исходного кода, поэтому под каждым корневым каталогом исходного кода есть структура database.
В поддереве database есть каталог patch с (в большинстве ветвей) единственным дочерним каталогом. Этот каталог имеет имя vCurrent (например, если vCurrent равен 2.3 SP1 HF0, тогда каталог исправлений будет называться 2.3 SP1 HF0) и содержит исправления, которые обновят схему базы данных (возможно, с преобразованием данных) с vCurrent до vFeature. vFeature, здесь - версия, в которой рассматриваемая ветвь идет в производство; это может быть vNext, vFuture или (в крайних случаях) vNever, если разработка по какой-то причине не удалась. Обычно ветви функций не имеют целевой версии выпуска, но могут иметь целевую дату выпуска.
Следовательно, структура выглядит примерно так:
main
database
patch
2.3 SP1 HF0 <--- indicating that "main" is at version 2.3 SP1 HF0
projectgroup1
main
database
patch
2.3 SP1 HF0
project1
main
database
patch
2.3 SP1 HF0
feature1
database
patch
2.3 SP1 HF0
Теперь представьте, что в работе обнаружена критическая ошибка, которая требует немедленного исправления, в результате чего main до версии 2.3 SP1 HF1. Или руководство решает выпустить релиз (возможно, только с одной ветвью функций), чтобы удовлетворить требования рынка, что дает нам 2,4 SP0 HF0. Или что угодно. Патчи "из" 2.3 SP1 HF0, которые не были применены в выпуске, могут или не могут быть применимы, но самое главное, это должно решаться в каждом конкретном случае разработчиком, ответственным за каждую ветку. Таким образом, создается новый каталог патчей с новым номером текущей версии, а старый удаляется, потому что он больше не актуален (он все еще доступен из системы контроля версий, также проверяя «показать удаленные элементы»). как в ветке выпусков релиза, так что доступ к содержимому определенного выпуска не является проблемой). При объединении этого набора изменений со своими соответствующими ветвями функций каждый разработчик должен просматривать свои наборы исправлений базы данных и обновлять их по мере необходимости, чтобы соответствовать любым изменениям схемы, исходящим от восходящего потока.
Обычно это не является большой проблемой, так как изменения в структуре патча вносятся в самый верхний main (что опять-таки стабильно) и стекают вниз.
Однако, , если существует вторая (до выпущенной) ветки функции со своим собственным набором патчей базы данных, TFVC выполнит операцию удаления в каталоге патчей main 2.3 SP1 HF0 main. по-видимому, без учета того факта, что вторая ветвь функции добавила содержимое в удаленный каталог и удалила эти новые исправления вместе с patch\2.3 SP1 HF0. Это явно нежелательно.
На мой взгляд, ситуация в ветви функций 2 является конфликтом: одна сторона слияния говорит об удалении, а другая говорит о новых файлах, которые никогда не были объединены с источником слияния. В этой ситуации TFVC должен отойти в сторону, представить это как конфликт и спросить программиста, который выполняет слияние, что делать. Обратите внимание, что в этом каталоге могут даже находиться файлы с одинаковыми именами, но разным содержимым (это сделано специально). Вместо этого он просто вытаскивает коврик из-под ваших ног, удаляя каталог и все его содержимое сразу.
В настоящее время мы в основном имеем дело с этим, выполняя «отмену ожидающих изменений» в удалении, затем перемещая новые патчи и удаляя старый каталог вручную. Это явно кажется неоптимальным, а также чрезвычайно рискованным (все, что нужно, - это один разработчик, не проверяющий полный набор ожидающих изменений, прежде чем объединять «незначительные» изменения из исходной, в то время как у них есть локальные исправления базы данных, и вы потеряли работа и много разочарований).
Работая в границах TFS и TFVC (поэтому, пожалуйста, не говорите «используйте Git в режиме DVCS» или тому подобное), Есть ли способ на самом деле представить это как конфликт? Или нам не повезло, и нам просто нужно разобраться с этой ситуацией вручную? Это случается не очень часто, но при большом количестве веток существует риск проскальзывания ошибки.