Политика контроля исходного кода

Документ «потоковые линии: шаблоны ветвления для параллельной разработки программного обеспечения» представляет собой отличное обсуждение паттерны ветвления, такие как паттерн «основная линия», который вы упомянули - в нем перечислены варианты в форме паттернов вместе с обсуждением антишаблонов. Один из авторов - Роберт Оренштейн из Perforce.

Нет пустых сообщений фиксации.

В нашем проекте мы используем несколько практических правил в качестве политики коммитов. Эти правила помогают нам держать каждую ревизию в состоянии готовности к развертыванию. Наши правила аналогичны политике фиксации KDE, опубликованной здесь: http://techbase.kde.org/Policies/SVN_Commit_Policy. Каждая фиксация должна быть (от более высокого до более низкого приоритета):

• Успешно проверено (скомпилировано, протестировано, рассмотрено, FxCop'ed и т. Д.)
• Атомарный (должен содержать только одно логическое изменение, например исправление одной ошибки, рефакторинг и т. Д.)
• Без избыточности (не следует добавлять неиспользуемый код, не фиксировать закомментированный код, не удалять его, не фиксировать случайные изменения формата и т. Д.)
• Правильно и полностью прокомментировано
• Соответствующая текущая фаза разработки (например, в ветках поддержки версий нельзя допускать рефакторинга)
• Как можно меньше, чтобы соответствовать предыдущим правилам.

Мы разработали простой инструмент SvnCommitChecker, который помогает нам проверить некоторые из этих правил перед фиксацией в svn. Я планирую выложить его в sourceforge в ближайшем будущем со статьей о преимуществах сохранения хорошей истории изменений svn.

Я отлично использовал книгу Practical Perforce. Хотя вы, возможно, не работаете с Perforce, я думаю, что глава 7 (Как развивается программное обеспечение) и глава 8 (Основы управления строкой кода) могут быть очень полезны. Возможно, вы сможете просмотреть их в Google Книгах.

У Perforce также есть много замечательных статей на эту тему. Моделирование жизненного цикла программного обеспечения пишет о политиках.
Perforce complete техническая документация.

И нет, я не работаю ни с Perforce.

Удачи Томас

По сути, это одно и то же:
Контроль версий для нескольких Agile-команд
Стратегия ветвления управления конфигурацией

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

Существует некоторая проблема с Subversion, поскольку она не может обрабатывать Циклическое слияние, но его можно обойти, удалив ветвь разработки после каждой реинтеграции обратно в магистраль (не имеет отношения к другим системам контроля версий)

Моя любимая политика: «Никаких подрывных коммитов, которые не ссылаются на билеты + комментарии Auto Trac для каждой фиксации»: http://trac.edgewall.org/browser/trunk/contrib/trac-post-commit-hook

Не фиксируйте / не фиксируйте изменения, которые нарушают сборку.

Зафиксируйте для каждого изменения, а не для каждого файла.

Это дает следующие преимущества:

• Позже вы увидите, почему эта единственная строка была изменена именно в этом файле (ага, это было исправление ошибки № 123). Если вы фиксируете для каждого файла, то сообщения о фиксации обычно описывают изменения, внесенные в файл, что вы в любом случае можете увидеть с помощью diff. Если вы фиксируете каждое изменение, сообщения фиксации обычно объясняют, почему это изменение было сделано в первую очередь.
• Намного проще отменить или объединить изменения / исправления.
• Это помогает лучше организовать вашу работу, поскольку вы четко сосредотачиваетесь на одной ошибке / функции / изменении, над которыми работаете. Вы делаете коммит, когда закончите.

Некоторые люди думают, что эта политика дает больше коммитов, но, судя по моему опыту, вы все же получаете меньше коммитов. Например, вы выполняете рефакторинг, который затрагивает 50 файлов. После рефакторинга у вас есть единственный коммит с сообщением «Рефакторинг подсистемы xyz.».

Для больших изменений вам следует рассмотреть политику dev-branch-per-change.