Общепринятая практика для Подверсии

Ветви - хорошая идея для внесения больших, возможно критических изменений. Если ствол обновляется одновременно, время от времени объединяйте ствол с ветвью, чтобы ветка обновлялась.

Зафиксируйте атомарный набор связанных изменений. Не делайте больших коммитов с несвязанными изменениями во всем. Это значительно упрощает отслеживание конкретных изменений.

У вас может быть несколько проверок одного и того же источника - полезно, если вы экспериментируете с несвязанными изменениями.

Избегайте фиксации неработающего кода или кода с ошибочными тестами или с другими нерешенными проблемами.

Существует много вариантов рабочих процессов управления исходным кодом. Тот, который мы используем, является расширением того, что вы описываете в своем сообщении. Ваш рабочий процесс достаточно хорош для незначительных модификаций, но не в том случае, если у вас есть несколько команд, работающих над разными проблемами значительной сложности.

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

Этот подход ветвь - объединить ... объединить - объединить обратно - удалить

Если вы новичок в SVN, то хорошим (бесплатным) ресурсом является SVN Book (копии мертвого дерева также можно купить у О'Рейли).

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

Я бы постарался делать коммиты как можно чаще. Чтобы разрешить это, вы должны убедиться, что код, который вы пишете, либо еще не используется, либо таков, что все тесты проходят. Если вы остаетесь в одном из этих двух режимов (последний намного лучше первого), вам не нужно беспокоиться о тех больших периодах, когда вы не можете совершить фиксацию.

TDD очень помогает в этом уважение.

Вы всегда должны делать обновление перед фиксацией, чтобы предотвратить возможные конфликты с другими сделанными фиксациями. другими людьми и болезненными слияниями.

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

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

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

Если "функция" потребует более нескольких (4-6) часов, я бы либо

• разделил " функция "на подзадачи, которые могут быть выполнены за несколько часов и проверены в системе управления версиями
• , создать ветвь
• как из вышеперечисленных

Недавно я участвовал в усовершенствовании методов управления конфигурацией программного обеспечения (SCM), используемых в компании, в которой я работаю. Мы обнаружили, что и «ветвление для разработки», и «ветвление для выпуска» работают достаточно хорошо.

Хорошая книга по шаблонам / стандартным процедурам SCM, которая мне показалась полезной, - это «Шаблоны управления конфигурацией программного обеспечения: эффективная совместная работа, практическая интеграция», автор Berczuk и Appleton ".

Еще несколько примечаний: (постарались не повторять то, что уже было сказано ..)

Ветви:

1. Помимо ветвления для больших фрагментов разработки функций, упомянутых выше, вы можете ветвь, когда вам нужно поработать над исправлениями после выпуска, в то время как параллельная работа продолжается над основной веткой / основной веткой.

2. Регулярно выполняйте обратное слияние, если вы используете ветки, которые живут долго, не будучи объединенными с основной разработкой. Это поможет синхронизироваться с развитием ствола и свести к минимуму сложности слияния большого взрыва.

3. Обратите внимание на то, как вы называете свои ветви. Мы стараемся называть ветви в честь вехи, на которой они основаны. Это помогает, когда вам нужны быстрые различия или отчеты, или даже когда вы что-то просматриваете, если названия говорят сами за себя.

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

Коммиты:

1. Я голосую за коммиты часто и по логическим фрагментам, чтобы вы могли связать связанные файлы общим сообщением о коммитах. Это отлично подходит для случаев, когда вам нужен журнал, а отчеты делаются по частям с кучей файлов, аккуратно связанных с соответствующими комментариями.

2. Я голосую за частые коммиты, если не каждый день. Это образ мышления. Как только вы увидите преимущества ранних коммитов (конечно, после того, как разработчики проверили основные ошибки компиляции и запустили модульные тесты в своем окне разработчика), вы будете счастливы отловить эти ранние ошибки / проблемы сборки. Если вы планируете запускать ночные сборки или использовать инструмент непрерывной интеграции, вам лучше попросить людей сделать коммит как можно раньше, чтобы получить представление об интегрированных потоках работы и запустить на них тесты.

Теги:

1. Придерживайтесь соглашений об именах выпусков - хотя это кажется тривиальным, помогает иметь хорошие имена тегов. Также убедитесь, что комментарии коммита к тегам точно указывают, почему вы помечаете эту версию репозитория. Мы помечаем теги только тогда, когда выполняем этапные сборки, поэтому в нашем случае мы сопоставляем сообщения фиксации тега с номером непрерывной сборки (тег круизной сборки), который мы используем для данной сборки. Также помогает определить схему нумерации релизов и поля, чтобы вы могли использовать их для тегов.

Если вы новичок в SVN, то хорошим (бесплатным) ресурсом является SVN Book (мертвый -копии деревьев также можно купить у О'Рейли)

.