Ветвление и слияние стратегий
4 ответа
Это единственный лучший шаблон управления исходным кодом , с которым я столкнулся. Это подчеркивает важность того, чтобы в багажнике не было мусора (без мусора в багажнике). Разработка должна выполняться в ветвях разработки, и регулярные слияния (после тестирования кода) должны производиться обратно в ствол (рис. 1), но модель также позволяет исправлять исходный код, пока он еще находится в разработке (рис 2). Я определенно рекомендую прочитать сообщение целиком, чтобы полностью понять.
Pic 1
Pic 2
Edit: Без слов картинки определенно сбивают с толку. Я мог бы объяснить, но в основном копировал бы первоначального автора. Сказав это, я, вероятно, должен был выбрать более качественную картинку для описания процесса слияния, так что, надеюсь, это поможет. Однако я все же рекомендую прочитать этот пост: 
Книга по подрывной деятельности описывает некоторые общие шаблоны ветвления . Возможно, вы также сможете применить их к TFS.
Самый простой и обычный способ, который я видел, - это разветвление из двух помещений. Багажник и выпуск. Я думаю, это известно как философия «Нестабильная магистраль, стабильная ветвь».
Магистраль - ваш основной источник. Он содержит «самый последний и лучший» код и рассчитан на перспективу. Как правило, он не всегда стабилен.
Выпуск - это ассоциация «один ко многим» с транком. Существует один ствол, но многие выпуски являются производными от ствола. Релизы обычно начинаются с ветви основной ветви после того, как достигается определенный рубеж функциональности, поэтому «единственными» вещами, которые нужно сделать для конкретного развертывания, должны быть просто исправления ошибок. Затем вы разветвляете ствол, присваиваете ему ярлык (например, 1.6 Release - это наш текущий последний выпуск), компилируете и отправляете выпуск QA. На этом этапе мы также подталкиваем номер версии (обычно младший номер) магистрали, чтобы убедиться, что у нас нет двух выпусков с одинаковым номером.
Затем вы начинаете цикл тестирования вашей ветки выпуска. После проведения достаточного тестирования вы применяете исправления ошибок к ветке выпуска, объединяете их обратно в магистраль (чтобы исправления ошибок переносились вперед!), А затем повторно выпускаете сборку ветки. Этот цикл с QA продолжается до тех пор, пока вы оба не будете довольны, и релиз, наконец, не будет предоставлен клиенту (ам). Любые отчеты об ошибках от клиентов, которые являются точными (т. Е. Являются ошибкой!), Начинают новый цикл контроля качества с рассматриваемой веткой.
По мере создания будущих выпусков неплохо также попытаться переместить старых клиентов на новые ветки, чтобы уменьшить возможное количество веток, в которые вам может потребоваться исправление ошибки.
Моя первая рекомендация - прочитать Эрика Синка Source Control HOWTO , в частности главы веток и слияния ветвей .
У нас есть 3 контейнера - DEV, MAIN и RELEASE для нашей работы. MAIN содержит весь наш «готовый к выпуску» код, и мы склонны думать о нем как о «в основном стабильном». DEV / Iteration (или DEV / Feature, или DEV / RiskyFeatureThatMightBreakSomeoneElse) являются ответвлениями от MAIN и объединяются, когда Iteration / Feature готовы к продвижению выше среды DEV. У нас также есть сборки TFS, настроенные из веток DEV / Iteration и MAIN.
Наш контейнер RELEASE содержит пронумерованные выпуски (аналогично контейнеру «теги», используемому во многих репозиториях Subversion). Мы просто каждый раз берем ветку из MAIN - я люблю говорить, что мы «разрезаем» ветку RELEASE, чтобы показать, что после слияния не должно происходить много действий.
Что касается VSS-> TFS - Microsoft поддерживает путь обновления , который должен хранить вашу историю версий, но если она вам не нужна, я бы просто получил последнюю версию из VSS, проверьте ее в TFS и заархивируйте репозиторий VSS.
И последний совет - ознакомьте членов вашей команды с системой управления версиями. Они должны понимать ветвление и слияние , иначе вы застрянете, выполняя много работы по очистке :).
Удачи!
TFS - Microsoft поддерживает путь обновления , который должен хранить вашу историю версий, но если она вам не нужна, я бы просто получил последнюю версию из VSS, проверьте ее в TFS и заархивируйте репозиторий VSS.И последний совет - ознакомьте членов вашей команды с системой управления версиями. Они должны понимать ветвление и слияние , иначе вы застрянете, выполняя много работы по очистке :).
Удачи!
TFS - Microsoft поддерживает путь обновления , который должен хранить вашу историю версий, но если она вам не нужна, я бы просто получил последнюю версию из VSS, проверьте ее в TFS и заархивируйте репозиторий VSS.И последний совет - ознакомьте членов вашей команды с системой управления версиями. Они должны понимать ветвление и слияние , иначе вы застрянете, выполняя много работы по очистке :).
Удачи!