My<cod/>.net
Организация репозитория
Когда я впервые начал использовать системы контроля версий , такие как CVS и SVN, я действительно не понимал концепции "trunk", ветвления, слияния и маркировки. Теперь я начинаю понимать эти концепции, и действительно понимаю важность и силу, стоящие за ними.
Итак, я начинаю делать это правильно. Или мне так кажется... Это то, что я понимаю до сих пор: последняя версия/стабильная версия вашего кода должна сидеть в /trunk/, в то время как бета-версии или версии bleeding edge находятся внутри каталога /branches/ как разные каталоги для каждого бета-релиза, а затем объединяются в магистраль при выпуске.
Не слишком ли упрощенный взгляд на вещи? Какие макеты репозитория вы, ребята, рекомендуете? Если это имеет значение, я использую Subversion.
То, что я делаю и обычно вижу как стандарт, - это:
Ствол должен содержать вашу основную линию развития, вашу нестабильную версию. Вы должны создать ветви релизов для своих релизов.
Что-то вроде:
/trunk (здесь вы разрабатываете версию 2.0) /branches/RB-1.0 (это ветвь выпуска для 1.0) /branches/RB-1.5
Когда вы находите ошибку в 1.5, вы исправляете ее в ветке RB, а затем объединяетесь с магистралью.
Я также рекомендую эту книгу .
У Эрика есть отличная серия статей по использованию системы управления версиями и передовым методам организации. Глава 7 посвящена филиалам (и да, она рекомендует каталоги /trunk/ и /branches/, которые вы предлагаете).
Я использовал Perforce в течение длительного времени, и поэтому мои комментарии могут быть немного ориентированы на Perforce, но основные принципы применимы к любому программному обеспечению SCM, которое имеет половину приличного ветвления. Я очень сильно верю в использование разветвленных методов разработки. У меня есть "main" (он же "mainline"), который представляет кодовую базу отныне и до вечности. Цель состоит в том, что это, в большинстве случаев, стабильно, и, если толчок пришел к толчку, вы можете сократить выпуск в любое время, что будет отражать текущую функциональность системы. Эти надоедливые продавцы продолжают спрашивать....
События происходят в ветвях, которые ветвятся от MAIN (обычно-иногда вы можете захотеть ветвиться от существующей ветви dev). Интегрируйтесь с MAIN в свои ветви разработки так часто, как вы можете, чтобы остановить слишком большие расхождения - или вы можете просто запланировать больший период интеграции позже. Только интегрируйте свою задницу, пиная новую функцию в MAIN, когда вы уверены, что она выйдет в предстоящем выпуске.
Наконец, у вас есть строка RELEASE, которая является опцией разных ветвей для разных выпусков. Существует несколько вариантов в зависимости от возможностей маркировки вашего программного обеспечения SCM и того, насколько разными могут быть основные/незначительные изменения. Таким образом, вы можете выбрать, например, ветвь выпуска для каждого выпуска точки или только для основного номера rev. Ваш пробег может отличаться.
Как правило, ветвь от MAIN выпускать как можно позже. Исправления ошибок и изменения в последнюю минуту могут либо перейти прямо в RELEASE для последующей интеграции в MAIN, либо в MAIN для немедленного резервного копирования интеграции. Там нет жесткого и быстрого правила-делать то, что работает лучше всего. Если, однако, у вас есть изменения, которые могут быть отправлены в MAIN (например, из ветки dev или "little tweaks" кем-то на 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 исправление отличается.
Что действительно отличает кодовые линии, так это политики, которые вы используете для управления ими. Например, какие тесты запускаются, кто проверяет до / после изменения, какое действие происходит, если сборка ломается. Обычно политики - и, следовательно, накладные расходы-являются самыми сильными в ветвях выпуска и самыми слабыми в DEV. Здесь есть статья, которая проходит через некоторые сценарии и ссылки на другие полезные вещи.
Наконец, я рекомендую начать с простой структуры и вводить только дополнительные версии dev & по мере необходимости.
Надеюсь, что это помогает, а не stating-the-bleedin' - очевидно слишком много.