Когда вы должны филиал?

Question

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

Answer 1

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

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

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

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

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

---

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

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

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

Определение ветви означает также определение рабочего процесса слияния : вам нужно знать, где слить ветку, когда вы закончите с ней.
Для этого, глава 7 Practical Perforce (Лора ВИНГЕРД - О'Рейли) является хорошим введением (независимым от VCS) для объединения рабочих процессов между различными видами ветвей: " « Как программное обеспечение развивается » (pdf)

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

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

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

---

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

Answer 2

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

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

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

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

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

• Нед Бэтчелдер - Быстрый запуск ветвления Subversion

Answer 3

Все СКМ 21 века говорят вам:

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

Вы получаете:

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

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

• Git
• Mercurial
• Пластик СКМ

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

• 1038 * SVN *
• CVS
• 1042 * ВСС *
• TFS
• неволей

Answer 4

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

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

Answer 5

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

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

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

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

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

Answer 6

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

Answer 7

Я нахожу совет Лауры Вингер и Кристофера Зейвальда из 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 для подробного объяснения каждого из них и других рекомендаций.

Answer 8

Существуют различные цели для ветвления:

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

Answer 9

Всякий раз, когда вам хочется.

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

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

Answer 10

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

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