Организация хранилища

Question

Когда я впервые начал использовать системы контроля версий, такие как Резюме и SVN, Я действительно не понимал понятий "магистрали", ветвления, слияния и пометки.Сейчас я начинаю понимать эти концепции и действительно осознаю важность и мощь, стоящие за ними.

Итак, я начинаю делать это правильно.По крайней мере, я так думаю...Это то, что я понимаю до сих пор:Последний выпуск / стабильная версия вашего кода должна находиться в /trunk/ , в то время как бета-версии или расширяющиеся версии находятся внутри каталога /branches/ в виде разных каталогов для каждого бета-релиза, а затем объединяются в trunk при выпуске.

Не слишком ли упрощенный взгляд на вещи?Какие макеты репозиториев вы, ребята, рекомендуете?Если это что-то изменит, я использую Subversion.

Answer 1

Смотрите эти два вопроса на SO для получения дополнительной информации:

• Что на самом деле означают ветвь, тег и магистраль?
• Вопрос о подрывной деятельности

Answer 2

То, что я делаю и обычно рассматриваю в качестве стандарта, это:

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

Что -то вроде:

/trunk (здесь вы разрабатываете версию 2.0) /branches/RB-1.0 (это ветка выпуска 1.0) /branches /RB-1.5

Когда вы обнаруживаете ошибку в 1.5, вы исправляете ее в ветке RB, а затем объединяете с магистралью.

Я также рекомендую эта книга.

Answer 3

У Эрика есть отличная серия статей об использовании системы управления версиями и лучших организационных практиках.Глава 7 посвящена филиалам (и да, он рекомендует каталоги /trunk/ и /branches /, которые вы предлагаете).

Answer 4

Я использую Perforce в течение длительного времени, и поэтому мои комментарии могут быть немного навязчивыми, но основные принципы применимы к любому программному обеспечению SCM, которое имеет хотя бы наполовину приличное ветвление.Я очень твердо верю в использование разветвленных методов разработки.У меня есть "main" (он же "mainline"), который представляет кодовую базу от настоящего момента до вечности.Цель состоит в том, чтобы в большинстве случаев это было стабильно, и, если понадобится, вы могли бы в любое время выпустить релиз, который отражал бы текущую функциональность системы.Эти надоедливые продавцы продолжают спрашивать....

Разработки происходят в ветвях, которые ответвляются от MAIN (обычно - иногда вы можете захотеть ответвиться от существующей ветви разработки).Интегрируйтесь из MAIN в свои ветви разработки как можно чаще, чтобы избежать слишком большого расхождения - или вы можете просто запланировать больший период интеграции позже.Интегрируйте свою новую функцию "надирания задниц" в MAIN только тогда, когда вы уверены, что она появится в следующем выпуске.

Наконец, у вас есть строка ВЫПУСКА, в которой доступны разные ветки для разных выпусков.Существует несколько вариантов в зависимости от возможностей маркировки вашего программного обеспечения SCM и того, насколько разными могут быть основные / второстепенные версии.Таким образом, вы можете выбрать, например, ветку выпуска для каждого точечного выпуска или только для основного номера версии.Ваш пробег может отличаться.

Как правило, переходите от MAIN к 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/...

Нетривиальный проект, вероятно, будет иметь несколько активных ветвей разработки одновременно.Когда разработка будет интегрирована в MAIN, так что теперь она является частью основного проекта, уничтожьте старую ветку разработки как можно скорее.Многие инженеры будут относиться к ветке разработки как к своему личному пространству и со временем будут использовать ее для различных функций.Препятствуйте этому.

Если после выпуска вам нужно исправить ошибку, то сделайте это в соответствующей ветке выпуска.Если ошибка была ранее исправлена в MAIN, затем интегрируйте ее по всему, если только код не изменился настолько сильно в MAIN, что исправление отличается.

Что действительно отличает кодлайны, так это политики, которые вы используете для управления ими.Например, какие тесты запускаются, кто проверяет изменения до / после внесения изменений, какие действия происходят, если сборка прерывается.Обычно политики - и, следовательно, накладные расходы - наиболее сильны в ветвях выпуска и наиболее слабы в разработчиках.Там есть статья здесь это проходит через некоторые сценарии и дает ссылки на другие полезные вещи.

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

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