Когда необходимо перейти?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отделение, когда вы узнаете, что его легче сливаться!

Имея в виду, что объединение всегда будет осуществляться с тем, как работа проводится в проекте.

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

Всякий раз, когда вы чувствуете, что это.

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

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

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

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

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

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

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

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

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

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

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

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

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

• Активные потоки разработки: постоянная кодировка, когда происходят последовательные различные разработки
• tasks branches: недолговечные ветки для более конкретной задачи (исправление ошибки является классическим, но вы также можете определить ветку для слияния, которое, как вы знаете, будет сложным для завершения: вы можете произвести слияние, коммит и тестирование в этой ветке задачи без введения проблемы для основной текущей ветки разработки)
• staging branch: для подготовки релиза, с некоторыми специфическими для пре-продукции данными или конфигурационными файлами.
• частные ветки, специальные ветки и разреженные ветки: для очень маленьких задач просто для того, чтобы иметь возможность зафиксировать некоторую незавершённую работу, не дожидаясь формального завершения или рецензирования теста.
  Это позволяет "делать коммиты пораньше, делать коммиты часто".

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

Вы заметите, что код

 using (var mre = new ManualResetEvent(false))
 {
    // Process the left child asynchronously
    ThreadPool.QueueUserWorkItem(delegate
    {
        Process(tree.Left, action);
        mre.Set();
    });

    // Process current node and right child synchronously
    action(tree.Data);
    Process(tree.Right, action);

    // Wait for the left child
    mre.WaitOne();
}

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

Посмотрите на http://www.worldtimezone.com/faq.html

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

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

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

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

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

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

• Git
• Mercurial
• Plastic SCM

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

• SVN
• CVS
• VSS
• TFS
• Perforce