Когда вы должны филиал?
Когда вы работаете с системой SCM, когда вам следует переходить?
12 ответов
Есть несколько применений для ветвления. Одним из наиболее распространенных применений является разделение проектов, которые когда-то имели общую кодовую базу. Это очень полезно для экспериментов с вашим кодом, не затрагивая основной ствол.
В общем, вы увидите два типа веток:
Ветвь компонента: если определенная функция достаточно разрушительна, и вы не хотите, чтобы вся команда разработчиков затрагивала ее на ранних этапах, вы можете создать ветвь, в которой будет выполняться эта работа.
Ветвь исправлений. Пока продолжается разработка основной ствола, можно создать ветвь исправлений, в которой будут содержаться исправления к последней выпущенной версии программного обеспечения.
Возможно, вас заинтересует следующая статья, в которой объясняются принципы ветвления и когда их использовать:
В общем, основная цель ветвления (VCS - система контроля версий - функция) заключается в достижении изоляции кода.
У вас есть хотя бы одна ветвь, которой может быть достаточно для последовательной разработки, и она используется для записи (выполнения) многих задач в этой же уникальной ветке.
Но эта модель быстро показывает свой предел:
Когда у вас есть усилия по разработке (рефакторинг, эволюция, исправление ошибок, ...) и вы понимаете, что вы не можете безопасно вносить эти изменения в ту же ветку, что и ваша текущая ветка разработки (потому что вы нарушите API или введете код, который нарушит все), тогда вам нужна еще одна ветка.
(Чтобы изолировать этот новый код для прежнего, даже если два набора кодов будут объединены позже)
Вот ваш ответ:
Вы должны выполнять ветвление всякий раз, когда вы не можете продолжить, и записывать две разработки в одной ветке.
(без ужасно сложной истории для поддержания).
Ветвь может быть полезна, даже если вы единственный, кто работает с исходным кодом, или если вас много.
Но вы не должны делать "одну ветку на разработчика":
цель "изоляции" предназначена для изоляции усилий по разработке (задача, которая может быть такой же общей, как "давайте разработаем следующую версию нашего программного обеспечения" или такой же конкретной, как "давайте исправим ошибку 23"),
не изолировать "ресурс".
(ветвь под названием "VonC" ничего не значит для другого разработчика: что, если "VonC" покинет проект? Что вы должны с ним делать?
например, ветвь с именем bugfix_212 может интерпретироваться в контексте системы отслеживания ошибок, и любой разработчик может использовать ее, по крайней мере, с некоторым представлением о том, что он должен с ней делать)
Ветвь - это не тег (SVN - это система редакций, которая пытается предложить функции управления версиями, такие как ветвление и маркировка в каталогах с дешевой копией файла: это не означает, что тег является ветвью)
Определение ветви означает также определение рабочего процесса слияния: вам нужно знать, где слить ветку, когда вы закончите с ней.
Для этого, глава 7 Practical Perforce (Лаура ВИНГЕРД - О'Рейли) является хорошим введением (VCS agnostic) для объединения рабочих процессов между различными видами ветвей: "
" Как программное обеспечение развивается " (pdf)
Он определяет термин codeline (ветвь, которая записывает важные этапы развития кода, либо через теги в определенных точках, либо через важное слияние с ветвью)
Он вводит основную модель (центральную кодовую линию для записи выпусков) и описывает различные цели ветвления:
- Активные потоки разработки: постоянная кодовая линия, когда происходят последовательные различные разработки
- ветви задач: недолговечные ветви для более конкретной задачи (исправление ошибок является классическим, но вы также можете определить ветку для усилий по слиянию, которые, как вы знаете, сложны для выполнения: вы можете объединять, фиксировать и тестировать в этой ветви задач без введения проблемы для основной текущей ветки разработки)
- промежуточная ветвь: для подготовки релиза, с некоторыми предварительными данными или файлами конфигурации.
- Частные ветви, специальные ветви и редкие ветви: для очень маленьких задач, просто для того, чтобы иметь возможность совершать некоторую работу в процессе, не дожидаясь официального завершения или проверки теста.
Это позволяет "совершать рано, часто совершать".
Другие интересные концепции вокруг VCS: Основные понятия
(первоначально о ClearCase, но также и для любых VCS)
Все СКМ 21-го века говорят вам:
Ветка для каждой задачи, над которой вы работаете, независимо от того, является ли это новой функцией, исправлением ошибки, тестом, чем угодно. Это называется ветвью темы, и она меняет способ работы с SCM.
Ты получаешь:
- Лучшая изоляция
- Лучшая прослеживаемость -> вы связываете задачи с ветвями, а не с отдельными ревизиями, что дает вам возможность фиксировать столько раз, сколько вы хотите, и не накладывает ограничение, например, "одна проверка на задачу".
- Задачи являются независимыми (обычно начиная со стабильной базовой линии, поэтому вы сосредотачиваетесь только на своем коде, а не на исправлении ошибок ваших людей), и вы можете выбрать, хотите ли вы интегрировать их в какой-то момент или позже, но они всегда находятся под контроль версий
- Вы можете легко просмотреть код (из контроля версий, а не из-за предварительной фиксации), прежде чем попасть в основную строку
Инструменты, которые могут это сделать:
Инструменты, которые НЕ МОГУТ это сделать:
- SVN
- CVS
- ВСС
- 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 для подробного объяснения каждого из них и других лучших практик.
Существуют различные цели для разветвления:
- Функция / ошибка веток. Динамические и активные ветви, которые перемещаются обратно в ствол, когда функция / исправление завершено.
- Статические ветви (теги в Subversion, хотя по сути это просто "нормальная ветвь"). Они предоставляют статический снимок, скажем, релиза. Хотя с ними можно работать, они остаются нетронутыми.
Необходимость ветвления также может возникнуть:
Когда вам нужно внести изменения, основанные на вашей текущей ветке, не предназначенные для следующего выпуска из этой ветки (и не раньше).
Например, мы обычно работаем на стволе. Во время релиза кому-то понадобится внести изменения, которые мы не хотим в текущем выпуске (это может быть до релиза, в данный момент обычно после релиза). Это когда мы разветвляемся, чтобы поместить выпуск в собственную ветку и продолжить разработку следующего релиза в транке.
Всякий раз, когда вы чувствуете, как это.
Вы, вероятно, не очень часто будете работать с централизованным SCM, так как ветви являются частью официального репозитория, и это не вызывает особых экспериментов, не говоря уже о том, что слияния действительно вредны.
OTOH, нет никакой технической разницы между веткой и проверкой в распределенных SCM, и слияния намного проще. Вы будете чувствовать себя как ветвь намного чаще.
Оставляя все технические детали в стороне.....
Филиал, когда вы знаете, что легче слить обратно!
Помните, что слияние всегда будет осуществляться в зависимости от того, как работа выполняется в проекте.
Как только это будет достигнуто, в игру вступят все остальные третичные вопросы.