Неправильная стратегия ветвления TFS - как исправить

Это то, что я должен делать, и нет ли лучшего выхода?

Я тщательно выполнял необоснованное слияние всех изменений из ветвей, release в trunk. Я бы сделал это один филиал за раз и объединил "Все изменения до определенной версии" и выделил всю "Последняя версия". Это даст вам багажник, который содержит все изменения из ваших релизов.

Должен ли я ожидать конфликтов или проблем здесь?

Вы можете столкнуться с конфликтами, но с некоторой осторожностью и некоторыми судебными расследованиями истории вы можете получить изменения в свой trunk.

Обычный процесс при работе с ветвями выпуска (даже те, которые напрямую не связаны с trunk) заключается в проверке в ветки релиза, а затем в RI (обратная интеграция) объединить изменение обратно в trunk. Некоторые люди предпочитают сначала проверять trunk а затем сливаются в ветку выпуска, чтобы избежать ситуации, когда trunk может быть забыт. Это шесть из одного, полдюжины других ИМО.

Должен ли я удалить текущие ветки "выпуска" и "R ***" или оставить их в качестве мусора?

Я не думаю, что это важно, вы можете перенести их в папку с obsolete releases если вы хотите скрыть их или просто удалить их - удаленные TFS будут мягкими.

Поделитесь своими мыслями и проблемами с моей стратегией или предложите лучшую

Я бы не стал stable. Как только у меня было все в trunk я был бы счастлив, цель магистрального/основного ветки - быть стабильной версией кода, если разработчики не смогут ее поддерживать (я не обвиняю их BTW), а затем работаю в ветких функций, и регулярное объединение FI в филиал функции - лучший способ.

Куда вы идете дальше, действительно зависит от процесса, который ваша компания имеет для релизов. Один из вариантов заключается в "маркировке" trunk когда у вас есть релиз, который вы хотели бы.

Start -----L:R1-----C->

Если вам нужно будет исправить ошибку до выпуска, вы можете разветкиться с метки:

Start -----L:R1-----C->
           |    /
     B:R1  |--C/

Проверьте изменение в ветки R1 (B: R1) и объедините его обратно в trunk.

Это дает вам ветку для выпусков, если необходимо, но не слишком глубокую структуру, вы можете столкнуться со многими ветвями, но вы можете использовать папки, чтобы их организовывать.

Надеюсь, что это поможет, в заключение убедитесь, что вы читаете руководство по разветвлению ALM Rangers - оно охватывает основные стратегии ветвления TFVC, которые вам, вероятно, понадобятся, и когда вы должны их использовать.

И, наконец, мой вопрос для всех, кто хочет создать филиал, - "Как вы отпустите этот код?", Это помогает мне создавать ветки для решения проблем, а не для создания проблем. Если я не знаю, как будет выпущен код, я не знаю, как лучше всего структурировать ветки - я когда-то был вовлечен в проект с иерархией из 23 веток от Main, что все собралось вместе, прежде чем протестированы или выпущены - мы могли бы использовать один :).

Последнее, если у вас есть учетная запись VSOnline или другая коллекционная коллекция Team Project, вы можете попробовать пересоздать более простую версию своей проблемы и поэкспериментировать с решениями.

Ваша стратификация слияния выглядит нормально для меня, но я постараюсь закончить с диаграммой трех ветвей.

Мы используем три ветки Dev, Test, Release.

большинство построек от dev и помечены. (так же, как туловище на вашей диаграмме). Затем мы переместим его на qa и продолжим развитие. Если в будущей разработке есть проблема \bug и ветвь Dev, мы устанавливаем ветвь тестирования на метку и исправляем проблему на тестовой ветке и объединяем ее для dev и снова и берем метку. Если у нас есть проблема с продукцией, мы используем метку в релизе, исправляем проблему, маркируем ее и, конечно, объединяем ее в dev. Это как все это делается с использованием трех ветвей.

Конечно, вы всегда можете использовать ветки функций для длинных и дезактивных функций.