Я использовал Perforce в течение длительного времени, поэтому мои комментарии могут быть немного ориентированными на Perforce, но основные принципы применимы к любому программному обеспечению SCM, которое имеет половину достойного разветвления. Я очень сильно убежден в использовании разветвленных методов развития. У меня есть «главный» (он же «магистраль»), который представляет собой кодовую базу отныне до вечности. Цель состоит в том, что в большинстве случаев это стабильно, и если толчок наступил, вы можете сократить выпуск в любое время, что отражает текущую функциональность системы. Эти надоедливые парни продаж продолжают спрашивать ...
События происходят в ветвях, разветвленных от MAIN (обычно - иногда вы можете перейти от существующей ветви dev). Интеграция из MAIN в ваши ветви dev настолько часто, насколько это возможно, чтобы остановить все, что слишком расходится - или вы можете просто запланировать более крупный интеграционный период позже. Только интегрируйте свою задницу с новой функцией в MAIN, когда вы уверены, что она выйдет в следующем выпуске.
И, наконец, у вас есть линия RELEASE, в которой есть опция разных ветвей для разных выпусков. Есть несколько вариантов в зависимости от возможностей маркировки вашего программного обеспечения SCM и того, насколько вероятны различные основные/незначительные изменения.Таким образом, вы можете выбрать, например, для ветви релиза для каждой точечной версии или только для основного номера оборота. Ваш пробег может отличаться.
Как правило, филиал от MAIN для выпуска как можно позже. Исправления и последние изменения могут либо перейти прямо в RELEASE для последующей интеграции в MAIN, либо в MAIN для немедленной интеграции. Там нет жесткого и быстрого правила - делайте то, что лучше всего работает. Если, однако, у вас есть изменения, которые могут быть отправлены в MAIN (например, из ветви dev или «небольшие настройки» кем-то из MAIN), выполните первый. Это зависит от того, как работает ваша команда, каковы ваши периоды выпуска и т. Д.
E.g. Я бы что-то вроде этого:
//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, это не так.
Что действительно отличает кодеки - это политики, которые вы используете для управления ими. Например, какие тесты запускаются, кто просматривает pre/post a change, какие действия происходят, если разрывается сборка. Как правило, политика - и, следовательно, накладные расходы - сильнейшая в релизах, и самая слабая в DEV. Есть статья here, которая проходит через некоторые сценарии и ссылки на другие полезные вещи.
Наконец, я рекомендую начать с простой структуры, чтобы начать с нее, и вводить дополнительные dev & при необходимости.
Надеюсь, что это поможет, и не говорит о том, что слишком много.