Когда нужно разветвляться?

Когда при работе с системой SCM следует выполнять ветвление?

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

В общем, вы увидите два типа веток:

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

• Ветка с исправлениями: пока продолжается разработка основного канала, можно создать ветку с исправлениями, в которой будут храниться исправления для последней выпущенной версии программного обеспечения.

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

• Нед Батчелдер - Быстрый старт ветвления Subversion

В общем, основная цель ветвления (функция VCS - Version Control System) - добиться изоляции кода .

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

Но эта модель быстро показывает свой предел:

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

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

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

(ветка под названием «VonC» ничего не значит для другого разработчика: что, если «VonC» выйдет из проекта? Что вы должны с этим делать?
ветку под названием «bugfix_212» можно интерпретировать, например, в контексте системы отслеживания ошибок , и любой разработчик может использовать его, хотя бы имея некоторое представление о том, что он должен с ним делать)

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

Определение ветки означает также определение рабочего процесса слияния : вам нужно знать, где слить ветку, когда вы закончите с ней.
В этой связи глава 7 Practical Perforce (Laura WINGERD - O'Reilly) является хорошим введением (независимо от VCS) для объединения рабочего процесса между различными типами ветвей: "" Как развивается программное обеспечение "(pdf)

Он определяет термин кодовая строка (ветвь, которая записывает важные этапы развития кода либо с помощью тегов в определенных точках, либо с помощью важного слияния с ответвлением)

В нем представлена ​​основная модель (центральная строка кода для записи релизов) и описаны различные цели ветвления:

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

_{Другие интересные концепции, связанные с VCS: Основные концепции
(изначально о ClearCase, но также действительны для любой VCS)}

Все SCM 21 века говорят вам:

Разделение для каждой задачи, над которой вы работаете , независимо от того, является ли это новой функцией, исправлением ошибки, тестом или чем угодно. Это называется тематической веткой, и она меняет способ работы с SCM.

Ты получаешь:

• Лучшая изоляция
• Лучшая прослеживаемость -> вы связываете задачи с ветвями, а не с отдельными наборами изменений, что дает вам возможность фиксировать столько раз, сколько вы хотите, и не накладывает ограничений, таких как «одна проверка на задачу».
• Задачи независимы (обычно начинаются со стабильного базового уровня, поэтому вы сосредотачиваетесь только на своем коде, а не на исправлении ошибок со стороны ваших людей), и вы можете выбрать, хотите ли вы интегрировать их в какой-то момент или позже, но они всегда ниже контроль версий
• Вы можете легко просмотреть код (из системы контроля версий, а не из ерунды перед фиксацией), прежде чем перейти к основной строке

Инструменты, которые могут это сделать:

• Git
• Mercurial
• Пластиковый СКМ

Инструменты, которые НЕ МОГУТ сделать:

• SVN
• CVS
• VSS
• TFS
• Волей случая

Это также зависит от инструмента SCM, который вы используете. Современные SCM (git, mercurial и т. Д.) Упрощают создание и уничтожение веток по мере необходимости. Это позволяет вам, например, создавать одну ветку для каждой ошибки, над которой вы работаете. Как только вы объедините свои результаты в ствол, вы отбрасываете ветку.

Другие SCM, например Subversion и CVS, имеют гораздо более «тяжелую» парадигму ветвления. Это означает, что ветка считается подходящей только для чего-то большего, чем патч из двадцати с чем-то строк. Там ветки обычно используются для отслеживания целых треков разработки, таких как предыдущая или будущая версия продукта.

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

Это зависит от того, какой тип SCM вы используете.

В более новых распределенных версиях (таких как git и mercurial) вы все время создаете ветки и все равно повторно объединяетесь. Я часто работаю над отдельной веткой какое-то время только потому, что кто-то сломал сборку на основной ветке, или потому что сеть не работает, а затем объединяю изменения обратно позже, когда это исправлено, и это так легко сделать, что это даже не раздражает .

Документ (короткий и читаемый), который больше всего помог мне понять, что происходит в распределенных системах: UnderstandingMercurial .

В более старых системах с центральным репозиторием (например, CVS, SVN и ClearCase) это гораздо более серьезная проблема, которую необходимо решать на уровне команды, и ответ должен быть больше похож на `` поддерживать старый выпуск, позволяя развитие, чтобы продолжить по основной линии », или« как часть большого эксперимента ».

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

Я считаю, что совет Лоры Вингерд и Кристофера Зайвальда из Perforce действительно краток и полезен:

* Branch only when necessary.
* Don't copy when you mean to branch.
* Branch on incompatible policy.
* Branch late.
* Branch, instead of freeze.

См. Http://www.perforce.com/sites/default/files/pdf/perforce-best-practices.pdf для подробного объяснения каждого из них и других передовых методов.

Цели ветвления могут быть разными:

1. Ветви функции / ошибки. Динамические и активные ветви, которые возвращаются в ствол после завершения исправления функции / ошибки.
2. Статические ветки (теги в Subversion, хотя по сути просто «нормальные ветки»). Они предоставляют статический снимок, скажем, выпуска. Хотя над ними можно работать, они остаются нетронутыми.

Также может возникнуть необходимость в разветвлении:

Когда вам захочется.

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

OTOH, нет технической разницы между веткой и кассой в распределенных SCM, а слияние намного проще. Вам захочется разветвляться намного чаще.

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

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

Оставив в стороне все технические детали ...

Разветвляйтесь, когда знаете, что легче слить обратно!

Помните, что слияние всегда будет происходить в соответствии с тем, как работа выполняется в проекте.

Как только это будет достигнуто, в игру вступят все остальные третичные вопросы.