Я использовал Perforce в течение длительного времени, поэтому мои комментарии могут быть немного ориентированы на Perforce, но основные принципы применимы к любому программному обеспечению SCM, которое имеет наполовину приличное ветвление.
Я очень твердо верю в использование разветвленных методов разработки. У меня есть «main» (он же «mainline»), который представляет кодовую базу от настоящего времени до вечности. Цель состоит в том, чтобы это в большинстве случаев было стабильным и, если бы наступил момент, вы можете в любой момент сократить выпуск, который бы отражал текущую функциональность системы. Эти надоедливые парни с продаж продолжают спрашивать ....
События происходят в ветвях, которые разветвляются от MAIN (обычно - иногда вы можете захотеть перейти от существующей ветки dev). Интегрируйте из MAIN в свои ветки разработчика так часто, как можете, чтобы не слишком сильно расходиться - или вы можете просто планировать бюджет на больший период интеграции позже. Интегрируйте свою задницу, пинающую новую функцию, в MAIN только тогда, когда вы уверены, что она выйдет в следующем выпуске.
Наконец, у вас есть строка RELEASE, в которой можно выбрать разные ветви для разных выпусков. Есть несколько вариантов в зависимости от возможностей маркировки вашего программного обеспечения SCM и от того, насколько вероятны будут различные основные / второстепенные версии. Таким образом, вы можете выбрать, например, ветвь релиза для каждой версии релиза или только для номера основной версии. Ваш пробег может варьироваться.
Как правило, ответвление от ОСНОВНОГО, чтобы выпустить как можно позже. Исправления и изменения, внесенные в последнюю минуту, могут быть отправлены прямо в RELEASE для последующей интеграции в MAIN или в MAIN для немедленного резервного копирования интеграции. Там нет жесткого и быстрого правила - делай то, что работает лучше всего. Если, однако, у вас есть изменения, которые могут быть отправлены в MAIN (например, из ветки разработчика или "небольшими изменениями" кем-то из MAIN), сделайте первое. Это зависит от того, как работает ваша команда, каковы ваши циклы выпуска и т. Д.
например. Я хотел бы что-то вроде этого:
//MYPROJECT/MAIN/... - the top level folder for a complete build of all the product in main.
//MYPROJECT/DEV/ArseKickingFeature/... - a branch from MAIN where developers work.
//MYPROJECT/RELEASE/1.0/...
//MYPROJECT/RELEASE/2.0/...
Нетривиальный проект, вероятно, будет иметь несколько активных веток DEV одновременно. Когда разработка была интегрирована в MAIN, и теперь она является частью основного проекта, как можно скорее убейте старую ветку DEV. Многие инженеры будут относиться к ветви DEV как к своему личному пространству и со временем использовать ее для различных функций. Не одобряйте это.
Если после выпуска вам необходимо исправить ошибку, сделайте это в соответствующей ветке выпуска. Если ошибка была ранее исправлена в MAIN, то интегрируйте через, если код не сильно изменился в MAIN, исправление отличается.
Что действительно отличает кодовые строки, так это политики, которые вы используете для управления ими. Например, какие тесты запускаются, кто просматривает данные до / после изменения, какое действие происходит в случае сбоя сборки. Обычно политики - и, следовательно, накладные расходы - самые сильные в ветвях релиза и самые слабые в DEV. Здесь есть статья , в которой рассматриваются некоторые сценарии и ссылки на другие полезные вещи.
Наконец, я рекомендую начать с простой структуры и вводить только дополнительные dev и release по мере необходимости.
Надеюсь, что это помогает, а не говорит о том, что истекает кровью слишком очевидно.