Когда я читаю вопрос, структура ветви выглядит примерно так:
D (Main)
--C (Dev)
----A (Developer1)
----B (Developer2)
--?Bugs
Быстрые термины (поэтому я могу использовать краткую запись):
- FI = Прямая интеграция (из родительской ветви в дочернюю)
- RI = обратная интеграция (от дочерней ветви до ее родительской ветви)
- Ветвь C является родителем ветви A и ветви B. A и B являются дочерними из C.
Исходный вопрос звучит так: существует следующее состояние:
- A и B имеют изменения, которые не были связаны с C.
- Вы отменили предыдущие попытки слияния в C, B и A.
- (?) Вы зафиксировали откат в каждой ветви (используя откат tf.exe ...), поэтому, когда вы «получаете последние» из каждой ветви, у вас есть рабочие версии, а не сбойные версии слияния.
Вот моя рекомендация:
- Откат к стабильным версиям A, B и C (если вы этого еще не сделали).
- C-> A, проверка, A-> C, проверка ОК.
- C-> B, проверка, B-> C, проверка в порядке.
подробности:
- Откат до рабочей версии A,
B и C (если вы этого не сделали
уже есть)
FI от C-> A (C до A)
- разрешить все конфликты, которые вы можете
- создать набор полок для вашего
в ожидании слияния
- Теперь тест в A
пока вы не уверены, что слияние было
успешно, и у вас есть все C, работающие со всеми A.
- Передать изменение слияния на A.
RI от A до C,
- Повторите шаги 2 и 3, начиная с C-> B, затем B-> C
СОВЕТ:"A" может быть в зависимости от того, какая ветка разработчика имеет самые простые или важные изменения.
* Если вы решите не фиксировать изменение для отката к более ранней «стабильной» версии, то вам, вероятно, нужно использовать опцию «Тип версии» ... но если во всех трех ветвях есть изменения, требующие отката, то вам по крайней мере нужно откатить c, затем объедините предыдущую версию A. Я лично предпочел бы начать со всех трех ветвей, чьи последние версии должны быть рабочими версиями, с которыми вы хотите продолжить. (Слияния уже достаточно сложны без необходимости слияния с конкретным набором изменений).
Сценарий, который вы описали, очень распространен, но не оптимален. Если и A, и B часто выполняют слияния с C (после выполнения FI и тестирования каждый раз), тогда ваша задача слияния будет намного меньше.
ДВИЖЕНИЕ ВПЕРЕД
Я пара рекомендаций, которые могут уменьшить ваши будущие боли слияния.
- Для повседневной работы разработчики могут использовать TFS shelvesets для ожидающих изменений, а затем переходить непосредственно в общую ветку dev. Полная ветвь требуется только в том случае, если вам требуется изоляция (например, работа с конфликтующими изменениями одновременно или ИЛИ несколько разработчиков, работающих над критическими изменениями)
- Создавайте дочернюю ветку из общей ветки разработчика только тогда, когда вам нужна изоляция от других изменений разработчика. Например, если вы реализуете критическое изменение, требующее работы обоих разработчиков, вы можете создать «функциональную» ветку, один или оба разработчика могут работать над этой функцией, не дестабилизируя ветку разработчика, а затем вернуться к ветви Dev, как только функция стабильна.
- FI Слияние от родителей к детям часто! В противном случае слияния становятся очень трудно согласовать.
У вас может быть слишком много веток для размера вашей команды (если у вас нет параллельных функций, которые не должны существовать бок о бок). Разумность уменьшается с количеством веток, которые вы находитесь вдали от Main. Я хотел бы, чтобы все разработчики работали из одной ветки Dev (C), а затем создавали ветку короткоживущего объекта только при необходимости (затем закрывали ветвь, как только функция стала достаточно стабильной для объединения с веткой Dev.
Руководство по ветвлению TFS - хороший ресурс для красивых картинок ветвления и множества советов, включая различные шаблоны, которые могут лучше удовлетворить ваши потребности в будущем.
Наслаждайтесь!-Zephan