До недавнего времени мой рабочий процесс разработки был следующим:
- Получить функцию от владельца продукта
- Сделать ветку (если функция больше 1 дня)
- Реализуйте это в ветке
- Объединить изменения из основной ветви в мою (чтобы уменьшить конфликты при обратном объединении)
- Слить мою ветку с главной веткой
Иногда возникали проблемы со слиянием, но в целом мне понравилось.
Но в последнее время я вижу все больше и больше последователей идеи не создавать ветки, поскольку становится все труднее практиковать непрерывную интеграцию, непрерывную доставку и т. Д. И это особенно забавно звучит у людей с распределенным опытом работы с VCS, которые так много говорили о замечательных реализациях слияния Git, Mercurial и др.
Итак, вопрос в том, должны ли мы использовать филиалы в наше время?
continuous-integration
branching
scm
SiberianGuy
источник
источник
Ответы:
Если вы не все работают из того же рабочего дерева, вы которые с ветками, их называют ли вы это или нет. Каждый раз, когда разработчик проверяет свое рабочее дерево, он создает отдельную локальную ветвь разработки, и каждый раз, когда он регистрируется, он выполняет слияние. Для большинства команд вопрос не в том , используете ли вы ветки, а в том, сколько и с какой целью ?
Единственный способ по-настоящему «непрерывной» интеграции состоит в том, чтобы каждый работал из одного и того же рабочего дерева. Таким образом, вы сразу узнаете, влияют ли ваши изменения на кого-то другого. Очевидно, это несостоятельно. Вам нужна определенная степень изоляции в ветке, чтобы чего-либо достичь, даже если эта «ветка» является просто вашим локальным рабочим каталогом. Что нужно, так это правильный баланс интеграции и изоляции.
По моему опыту, использование большего количества ветвей повышает степень интеграции, потому что интеграция выполняется именно с теми людьми, которых она должна выполнять, и все остальные могут легче изолировать несвязанные проблемы по мере необходимости.
Например, я провел последний день, отслеживая три недавно появившихся ошибки, связанных с интеграцией, в нашей сборке, которые блокировали мою «настоящую» работу. После того, как я сделал все возможное, чтобы сообщить об этих ошибках людям, которые должны их исправить, я должен просто ждать, пока они не закончат, чтобы продолжить мою работу? Конечно, нет. Я создал временную локальную ветвь, которая отменяет эти изменения, чтобы у меня была стабильная базовая линия, с которой можно работать, в то же время получая последние изменения из апстрима.
Без возможности создать новую ветку для этой цели я был бы ограничен одним из трех вариантов: либо отменить изменения в центральном репо, либо вручную сохранить патчи, которые возвращают их в моем рабочем дереве, и попытаться не случайно зафиксировать их в или вернуться к версии до того, как эти ошибки были введены. Первый вариант может сломать какую-то другую зависимость. Второй вариант - большая работа, поэтому большинство людей выбирают третий вариант, который, по существу, не позволяет вам выполнять больше работы по интеграции, пока ранее найденные ошибки не будут исправлены.
В моем примере использовалась частная локальная ветвь, но тот же принцип применяется к общим ветвям. Если я поделюсь своей веткой, то, возможно, 5 других людей смогут продолжить выполнение своих основных задач вместо выполнения избыточной работы по интеграции, таким образом, в совокупности выполняется более полезная работа по интеграции. Проблема с ветвлением и непрерывной интеграцией заключается не в том, сколько веток у вас есть, а в том, как часто вы их объединяете.
источник
Примерно полгода назад мне было поручено провести исследование, чтобы ответить на этот вопрос. Вот резюме, основанное на изученных ссылках (перечисленных ниже)
Рекомендации
http://msdn.microsoft.com/en-us/library/aa730834%28v=vs.80%29.aspx
http://www.cmcrossroads.com/bradapp/acme/branching/
http://www.codinghorror.com/blog/2007/10/software-branching-and-parallel-universes.html
http://www.lostechies.com/blogs/derickbailey/archive/2010/02/24/branching-strategies-when-to-branch-and-merge.aspx
http://www.snuffybear.com/ucm_branch.htm
Обратите внимание, что с учетом других ссылок, перечисленных здесь, утверждение автора о том, что «в данной статье описываются три ключевые модели ветвления, используемые в проектах разработки программного обеспечения» , не выглядит оправданным. Используемая терминология не выглядит широко распространенной ( EFIX , Model-1,2,3 и т. Д.).
http://svn.haxx.se/users/archive-2007-10/att-0101/SCMBranchingModels-talkback.pdf В
справочном материале представлен интересный пример трудностей, связанных с передачей стратегий ветвления.
http://simpleprogrammer.com/2010/06/04/simple-branching-strategy-part-1-back-to-basics/
... Сохраняйте это простым. На мой взгляд, наилучшим подходом является работа непосредственно с багажника.
Это звучит почти как ересь, когда я на самом деле печатаю его на экране, но если вы на мгновение потерпите меня, я не только покажу вам, почему я считаю, что это важно для Agile-процесса, но я покажу вам, как заставить его работать ...
... Если бы мне пришлось основывать свои рассуждения на одном веском аргументе, это была бы ценность непрерывной интеграции. Я написал в блоге о значении КИ и лучших практиках в прошлом. Я довольно большой сторонник CI ...
... Вы действительно должны задать себе вопрос здесь: «Все ли накладные расходы, которые вы несете в результате выполнения своей сложной стратегии ветвления и слияния, приводят к реальной ценности, которой не существует по сравнению с более простой стратегией?» ...
.. Стратегия, которую я эффективно использовал в прошлом и развивалась с течением времени. Я кратко подведу итог здесь.
...
... довольно подробный обзор ...
http://www.codelathe.com/blog/index.php/2009/07/02/a-svn-branching-strategy-that-works/
... Наконец, помните, что не существует идеальной стратегии ветвления и слияния. Это в значительной степени зависит от вашей уникальной среды разработки ...
http://blog.perforce.com/blog/?cat=62
... В худшем случае вы вводите проблему "семантического слияния", когда результат автоматического слияния неверен, но компилируется нормально и проходит мимо тестирование, возможно, даже длится достаточно долго, чтобы быть видимой клиентом ошибкой. Ик!
Добавляя оскорбление к травме, поскольку они могут дольше избежать обнаружения, проблемы с семантическим слиянием труднее исправить позже, поскольку изменение больше не является свежим в сознании разработчика, который создал это изменение. (Обычно лучше объединить изменения вскоре после их внесения, в идеале разработчиком, который инициировал изменение, если это целесообразно) ...
Примечание. Рекомендуемая политика выглядит аналогично ветви разработки, как это определено в http://www.infoq.com/articles/agile-version-control#q11 и http : //msdn.microsoft.com/en-us/library/bb668955.aspx
https://stackoverflow.com/questions/34975/branching-strategies
Члены сообщества делятся различным опытом в различных проектах с использованием различных стратегий ветвления. Нет согласованного консенсуса по «лучшему» или «худшему».
«классическое» чтение - объясненная терминология, такая как Mainline Model , Codeline и т. д.
http://www.stickyminds.com/s.asp?F=S16454_COL_2
По существу, краткое изложение материала, представленного в http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf
... Существует три распространенных подхода к решению, когда и как разветвляться:
... Обоснованием ветвления является изоляция кода в конце выпуска, чтобы он мог стабилизироваться. Изоляция посредством ветвления часто маскирует проблему качества, которая в конечном итоге проявляется в дополнительных затратах на поддержание параллельных потоков перед выпуском продукта. Ветвление легко. Скорее, это сложное объединение и когнитивные издержки понимания того, как происходят изменения между ветвями, поэтому важно выбрать процесс, который минимизирует стоимость ветвления и объединения ...
http://nvie.com/posts/a-successful-git-branching-model/ Git-ориентированная стратегия.
... Мы считаем origin / master основной ветвью, где исходный код HEAD всегда отражает состояние готовности к работе .
Мы считаем, что origin / development является основной ветвью, где исходный код HEAD всегда отражает состояние с последними внесенными изменениями разработки для следующего выпуска. Некоторые называют это «интеграционной ветвью». Это где любые автоматические ночные сборки строятся из ....
http://svnbook.red-bean.com/en/1.5/svn.branchmerge.html
... Политики проекта сильно различаются в зависимости от того, когда именно уместно создать ветку элементов. Некоторые проекты вообще никогда не используют ветви функций: коммиты на / trunk являются бесплатными для всех. Преимущество этой системы в том, что она проста - никому не нужно узнавать о ветвлении или слиянии. Недостатком является то, что транковый код часто нестабилен или непригоден для использования. Другие проекты используют ветвь до крайности: никаких изменений не всегда стремятся к стволу непосредственно. Даже самые тривиальные изменения создаются в недолгой ветке, тщательно проверяются и объединяются в ствол. Тогда ветка удаляется. Эта система гарантирует исключительно стабильную и пригодную для использования магистраль в любое время, но за счет огромныхнакладные расходы процесса.
Большинство проектов используют промежуточный подход. Они обычно настаивают на том, чтобы / trunk компилировал и проходил регрессионные тесты всегда. Функциональная ветвь требуется только тогда, когда изменение требует большого количества дестабилизирующих фиксаций. Хорошее практическое правило - задать этот вопрос: если разработчик работал в течение нескольких дней в изоляции, а затем совершил большое изменение сразу (так, чтобы / trunk никогда не был дестабилизирован), будет ли это слишком большим изменением для проверки? Если ответ на этот вопрос «да», изменение должно быть разработано в ветви функций. Поскольку разработчик вносит постепенные изменения в ветку, они могут быть легко просмотрены коллегами.
Наконец, возникает вопрос о том, как лучше поддерживать ветвь функции в «синхронизации» со стволом в процессе работы. Как мы упоминали ранее, существует большой риск работать на ветке в течение недель или месяцев; Изменения в стволе могут продолжать вливаться до такой степени, что две линии развития будут настолько сильно различаться, что это может стать кошмаром, пытаясь слить ветку обратно в ствол.
Эту ситуацию лучше всего избегать путем регулярного объединения изменений магистрали в ветку. Составьте политику: раз в неделю объединяйте изменения в магистрали за последнюю неделю с веткой ...
http://thedesignspace.net/MT2archives/000680.html
... Этот раздел учебника по Eclipse CVS основан на статье Пола Глезена на веб-сайте Eclipse: ветвление с Eclipse и CVS и используется с его разрешения в соответствии с условиями лицензия EPL. Изменения, которые я делаю в его версии, в основном заключаются в том, чтобы расширять ее, добавляя пошаговые изображения и объяснения, и интегрировать ее с моими собственными учебниками для начинающих, чтобы сделать ее более доступной для начинающих и дизайнеров. Опытные разработчики, вероятно, предпочтут работать с версией Пола ...
http://learnsoftwareprocesses.com/2007/12/29/common-branching-strategies/
... Вот некоторые из распространенных моделей ветвления:
http://msdn.microsoft.com/en-us/library/bb668955.aspx
... См. рекомендации по ветвлению и слиянию в «Руководстве по управлению исходным кодом» в этом руководстве для получения краткого описания рекомендаций по ветвлению и слиянию. ... При ветвлении учитывайте следующее:
Решение о создании ветви может быть сведено к тому, будет ли стоимость слияния конфликтов в реальном времени выше, чем накладные расходы на слияние конфликтов между ветвями ...
http://kashfarooq.wordpress.com/2009/11/23/bazaar-branching-strategy-with-a-subversion-trunk/
... Любая из этих жалоб Subversion звучит знакомо?
У меня есть хранилище Subversion на USB-накопителе. Я получаю конфликты деревьев и сливаю проблемы с этим, и я единственный пользователь!
Основная проблема - слияние ...
http://social.msdn.microsoft.com/Forums/en/tfsversioncontrol/thread/f127676c-8f05-410c-9a30-0eb43a26a9fa
обсуждение наилучшей практики для стратегии ветвления изоляции релизов в случае развивающихся систем.
http://branchingguidance.codeplex.com/
"Руководство по ветвлению на сервере Microsoft Team Foundation Server" - обширный и подробный документ с рекомендациями для разных проектов: здесь HTML-версия . Доказывает, что Microsoft не верит в универсальный подход к стратегиям ветвления.
https://stackoverflow.com/questions/597707/best-branching-strategy-when-doing-continuous-integration
Какую стратегию ветвления лучше использовать, если вы хотите осуществлять непрерывную интеграцию? ... Ответ зависит от размера вашей команды и качества исходного контроля и способности правильно объединять сложные наборы изменений ...
. Моим величайшим открытием было то, что, хотя КИ касается фиксации, подталкивания и получения обратной связи (т. Е. Кластер КИ предоставляет вам обратную связь, которую ваша рабочая станция никогда не сможет дать вам за такое же время), истинный пуристический КИ на самом деле имеет еще одно требование - что команда должна работать на той же базовой линии ...
Использованные материалы
http://codicesoftware.blogspot.com/2010/03/branching-strategies.html
... CVS и SVN не одобряли всю стратегию ветвления / слияния, поскольку они не могли этого сделать ... ... Простое правило: создайте ветку задач для каждой новой функции или исправления, которое вы хотите внедрить ... Для пользователей SVN / CVS это может показаться излишним, но вы знаете, что любой современный SCM позволит вам создавать ветки за секунду, так что никаких накладных расходов нет.
Важное примечание: если вы внимательно посмотрите на это, то увидите, что я говорю об использовании ветвей задач в качестве богатых списков изменений ...
http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.cc_proj.doc/c_bntr_plnbrstrat.htm
... Политика ветвления зависит от разработки Цели проекта и обеспечивает механизм для управления развитием кодовой базы. Вариантов политики ветвления так же много, как и организаций, использующих систему управления версиями Rational ClearCase. Но есть также сходства, которые отражают общую приверженность лучшим практикам ...
http://blogs.open.collab.net/svn/2007/11/branching-strat.html
... Модель Subversion (или более общая модель с открытым исходным кодом) - это то, что показано в нестабильной модели соединительных линий. ,
http://en.wikipedia.org/wiki/Trunk_%28software%29
В области разработки программного обеспечения транк ссылается на неназванную ветвь (версию) файлового дерева под управлением ревизии . Магистраль, как правило, должна быть основой проекта, на котором развивается развитие. Если разработчики работают исключительно над стволом, он всегда содержит самую последнюю версию проекта, но, следовательно, также может быть самой нестабильной версией. Другой подход состоит в том, чтобы отделить ветвь от магистрали, внедрить изменения в этой ветке и объединить изменения обратно в ствол, когда ветвь доказала свою стабильность и работоспособность. В зависимости от режима разработки и коммитаПолитика транк может содержать наиболее стабильную или наименее стабильную версию или что-то промежуточное.
Часто основная работа разработчика происходит в транке, а стабильные версии разветвляются, а иногда исправления ошибок объединяются из веток в транк. Когда разработка будущих версий выполняется в ветвях, не являющихся магистральными, обычно это делается для проектов, которые не меняются часто, или когда изменение, как ожидается, займет много времени для разработки, пока оно не будет готово для включения в магистраль. ,
http://www.mcqueeney.com/roller/page/tom/20060919
... Это заметки из вебинара по передовым методам Subversion , проведенного 30 августа 2006 г. CollabNet. ... Две организационные стратегии: нестабильный ствол против стабильного ствола ... ... ПРЕДПОЧИТАЙТЕ нестабильный ствол, когда это возможно ...
https://stackoverflow.com/questions/153812/subversion-is-trunk-really-the-best-place-for-the-main-development
В SVN транк - рекомендуемое место для основной разработки, и я использую это соглашение для всех моих проектов. Тем не менее, это означает, что транк иногда нестабилен или даже сломан ... ... не лучше ли выполнять "дикую разработку" в некоторой ветке, такой как / branch / dev, и объединяться с транком только при разумной сборке твердое вещество?
http://blog.yclian.com/2009/03/working-on-branches-and-stable-trunk.html
... Я работал над стволом, потому что для всех проектов, над которыми я работал, это либо я единственный разработчик или команда гарантировали, что каждая регистрация кода прошла локальные тесты. В противном случае мы создали (мы все еще) ветки для исправления ошибок, большой код для новых функций и т. Д.
Около 2 месяцев назад у меня была короткая сессия с Камалом, и он поделился со мной идеей истории / ветки . И так как моя команда начала расти с большим количеством разработчиков, я чувствую необходимость поощрять больше ветвлений, и теперь это стало правилом. Для проекта с автоматическими тестами, определенными с настройкой CI, стабильная магистраль гарантирована, и эта практика может очень хорошо в нее вписаться.
Мы используем не git, а Subversion, потому что так мы начинали, и сейчас мы по-прежнему довольны им (большую часть времени) ...
http://www.ericsink.com/scm/scm_branches.html
Это часть онлайновой книги под названием Source Control HOWTO , руководство по передовым методам управления исходным кодом, контроля версий и управления конфигурацией ...
... Предпочитаемое ветвление Эрика Тренируйтесь ... Держите "в основном нестабильный" багажник. Активно развивайтесь в стволе, стабильность которого возрастает по мере приближения к релизу. После отправки создайте ветку обслуживания и всегда сохраняйте ее очень стабильной ...
... В следующей главе я углублюсь в тему объединения веток ...
http://marc.info/?l=forrest-dev&m=112504297928196&w=2
Начальная почта потока, обсуждающего стратегии ветвления для проекта Apache Forrest
Документы о ветвлении CVS O'Reilly:
http://commons.oreilly.com/wiki/index.php/Essential_CVS/Using_CVS/Tagging_and_Branching#Basically_stable
... Более мягкие вариации также позволяют создавать ветки для экспериментального кода, рефакторинга и другого кода для особых случаев. Объединение филиала обратно в ствол осуществляется менеджерами филиала. ...
Лучшие практики в SCM (статья о выполнении) по адресу
http://www.perforce.com/perforce/papers/bestpractices.html
... шесть общих областей развертывания SCM и некоторые грубые лучшие практики в каждой из этих областей. В следующих главах объясняется каждый элемент ...
Рабочие пространства, Строки кода, Ветвление, Распространение изменений, Сборки, Процесс ...
источник
Если у вас есть несколько команд, работающих над различными функциями одновременно, вы не сможете пропустить ветвление. Вы должны делиться (частично реализованным) кодом с членами команды, чтобы другие команды не могли получить ваши незавершенные функции.
Филиалы - самый простой способ достичь этого.
Хотя хорошо бы сократить жизненный цикл веток и избегать работы с одним и тем же модулем в двух ветвях одновременно - тогда у вас не возникнет проблем с конфликтами \ слиянием.
источник
Ну это сделать более трудным практиковать непрерывную интеграцию, непрерывную доставку, и т.д. для вас конкретно?
Если нет, то я не вижу причин менять ваш способ работы.
Конечно, хорошей практикой является следить за тем, что происходит и как развиваются нынешние лучшие практики. Но я не думаю, что нам нужно отказываться от наших процессов / инструментов / еще чего-то только потому, что X (и / или Y и / или Z) сказали, что они больше не причуды :-)
источник
Какой интересный набор ответов. За 20 с лишним лет я никогда не работал в компании, которая использовала более чем тривиальное использование ветвления (как правило, только для отраслевых выпусков).
Большинство мест, в которых я работал, основаны на достаточно быстрой регистрации и быстром обнаружении / устранении коллизий - методология Agile учит, что вы можете решать проблемы быстрее, если заметите их, в то время как обе стороны активно думают об этом куске кода.
С другой стороны, я мало использовал git, и, возможно, именно ответ на эти ответы оказал влияние на эти ответы - я понимаю, что ветвь / слияние дано в git, потому что это так просто.
источник
Да, вы должны использовать ветки, чтобы изолировать любые (хотя бы средние) усилия по разработке. Смотрите « Когда вы должны разветвляться? ».
Проблема в том, чтобы использовать ускоренные слияния (которые включают в себя историю ветвлений внутри другого), при условии, что вы сначала уничтожите все «промежуточные фиксации контрольной точки» (которые могут быть проблемой в случае отката или
git bisect
).См. « Понимание рабочего процесса Git », чтобы отличить частные ветки (не предназначенные для отправки) от общедоступных ветвей, которые будут завершены слияниями ff (ускоренные слияния) при условии, что вы выполните необходимую очистку в ветке, которую вы объединяете ,
Смотрите также « Почему git использует ускоренное слияние по умолчанию? ».
источник
Вы должны обязательно использовать ветки. В этом есть ряд сильных сторон.
Слишком трудно никогда не оправдание. Всегда нужно больше усилий, чтобы сделать это правильно.
источник
Если две команды работают в своей собственной ветке, они не увидят изменений другой команды, даже если обе интегрируют
master
ветку. Это будет означать, что их ветки разработки будут расходиться, и если одна из команд сойдет с нейmaster
, другая команда должна отменить множество изменений.Поэтому, даже если у вас есть ветки для функций, я бы настоятельно рекомендовал вам создавать «обратные порты» всех рефакторингов в главную ветку и оставлять ветку только для новых функций.
Я думаю, что иногда было бы проще использовать переключатели функций для отключения новых, непроверенных функций, которые еще не должны быть запущены в производство. Таким образом, все другие команды увидят изменения, и слияние большого взрыва не должно произойти.
источник
Мы только что прошли через это (снова). Сначала у нас была целая дискуссия по GIT / SVN, которая привела нас к стратегиям ветвления в целом.
Все крупные компании используют основанную на соединительных линиях стратегию, когда все работают в одной и той же ветке, и из этой ветви происходят сборки и непрерывная интеграция. Предотвращение конфликтов осуществляется с помощью модульности кода, переключения функций и умных инструментов. Это звучит сложно .. потому что это так. Но если вы ведете эту дискуссию, это потому, что вы стали жертвой фантазий людей о ветвлении. Некоторые утверждают, что они используют инструмент вставки SCM с полностью совместимым с Sarbanes-Oxley механизмом продвижения, и это все блестяще. Они либо лгут, обманывают себя, либо не работают в той же системе, что и вы.
Разветвление и слияние сложно. Особенно если у вас есть бизнес, который регулярно меняет свое мнение, требует откатов и т. Д.
Это предложение может спасти вам жизнь: то, что находится в SCM, не то же самое, что в ваших встроенных артефактах!
Если у вас возникли проблемы с ветвлением, это потому, что вы неправильно используете SCM. Мы все делали это годами. У вас есть система, в которой SCM используется для определения того, что входит в вашу окончательную сборку.
Это не работа СКМ. SCM - это прославленный файловый сервер. Задача определения того, какие файлы из вашей SCM входят в вашу сборку, принадлежит вашему инструментарию сборки.
Модуль А находится в стадии разработки и входит в ваш еженедельный выпуск. Модуль B - это модуль A, но с проектом X в нем, и он работает в той же ветке, но не встроен в ваш выпуск. В какой-то момент в будущем вы захотите выпустить проект X. Таким образом, вы скажете своему инструменту сборки прекратить вставлять модуль A и начать вставлять модуль B.
Об этом будет много плача и скручивания рук. Что за невзрачный и вообще вой. Таков уровень эмоций, окружающих что-то столь же простое, как хранилище файлов, независимо от того, насколько оно умно.
Но есть твой ответ.
источник
Основная проблема с ветвлением - это сложность слияния с основной ветвью после завершения разработки. Слияние может быть ручным и подверженным ошибкам процессом, поэтому его следует избегать большую часть времени.
Некоторые заметные исключения, где я предпочитаю ветвление, - это масштабный рефакторинг, гигантские функции, для разработки которых требуется больше времени, чем спринт, или деструктивные функции, которые могут прервать разработку других функций в течение большей части этого спринта.
источник
Я рекомендую такую схему веток:
релиз - тест - разработка
Затем от разработки, ветки по разработчикам и / или по функциям.
У каждого разработчика есть ветка, с которой можно поиграть, слиться с ней, а затем в ветку разработки - в идеале каждый день (при условии, что она компилируется).
Такая схема действительно хорошо работает со многими разработчиками и несколькими проектами в одной кодовой базе.
источник
Мы делаем использовать ветви, но не на гранулированном уровне функции. Мы используем ветки для каждого спринта. Разветвление по сути не является плохой вещью IMO, потому что оно имитирует концепцию SOC в функциональном уровне или на уровне спринта. Вы легко можете распознать и управлять тем, какая ветвь принадлежит какой функции или спринту.
ИМХО, тогда ответ ДА . Мы все еще должны использовать ветвление.
источник
Процесс в моей организации широко использует филиалы и (процесс, который немного похож) непрерывную интеграцию.
На высоком уровне разработчики не слишком беспокоятся о слиянии с основной линией, они просто передают ветку. (полу) автоматизированный процесс проверяет, какие функции планируется включить в основную линию, объединяет эти ветви и создает продукт. Этот процесс работает, потому что мы фактически интегрируем этот процесс слияния из системы отслеживания проблем, чтобы инструмент сборки знал, какие ветви объединить.
источник