Разветвляться или нет?

До недавнего времени мой рабочий процесс разработки был следующим:

1. Получить функцию от владельца продукта
2. Сделать ветку (если функция больше 1 дня)
3. Реализуйте это в ветке
4. Объединить изменения из основной ветви в мою (чтобы уменьшить конфликты при обратном объединении)
5. Слить мою ветку с главной веткой

Иногда возникали проблемы со слиянием, но в целом мне понравилось.

Но в последнее время я вижу все больше и больше последователей идеи не создавать ветки, поскольку становится все труднее практиковать непрерывную интеграцию, непрерывную доставку и т. Д. И это особенно забавно звучит у людей с распределенным опытом работы с VCS, которые так много говорили о замечательных реализациях слияния Git, Mercurial и др.

Итак, вопрос в том, должны ли мы использовать филиалы в наше время?

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

Единственный способ по-настоящему «непрерывной» интеграции состоит в том, чтобы каждый работал из одного и того же рабочего дерева. Таким образом, вы сразу узнаете, влияют ли ваши изменения на кого-то другого. Очевидно, это несостоятельно. Вам нужна определенная степень изоляции в ветке, чтобы чего-либо достичь, даже если эта «ветка» является просто вашим локальным рабочим каталогом. Что нужно, так это правильный баланс интеграции и изоляции.

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

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

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

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

вопрос в том, должны ли мы использовать филиалы в настоящее время?

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

• нет общепринятой «лучшей» стратегии ветвления, применимой к любому проекту
  • большинство ресурсов сходятся во мнении, что выбор продуктивной стратегии зависит от конкретной специфики проекта
  • Примечание. Исходя из вышеизложенного, похоже, что любые изменения в стратегии ветвления проекта необходимо протестировать, измерить и сравнить с другими протестированными вариантами.
• Распространено мнение, что объединение с Subversion требует много усилий. Все, кто сравнивал SVN и Git, отмечают, что объединение с Git критически проще
• Важным фактором, по-видимому, является то, происходят ли производственные выпуски из магистральных или ответвлений. Команды, выполняющие выпуск релизов из транка (что кажется не очень популярным способом), по существу, запрещают использовать нестабильную стратегию транка . Команды, делающие релизы из веток, имеют больше вариантов ветвления на выбор.
• популярными стратегиями являются стабильный ствол, нестабильный ствол и ветка разработки (интеграции)

Рекомендации

• http://msdn.microsoft.com/en-us/library/aa730834%28v=vs.80%29.aspx
  

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

• http://www.cmcrossroads.com/bradapp/acme/branching/
  

  ... Частая, постепенная интеграция является одним из признаков успеха, а ее отсутствие часто является признаком неудачи. Современные методы управления проектами имеют тенденцию избегать строгих моделей водопадов и охватывают спиралевидные модели итеративного / поэтапного развития и эволюционной доставки. Стратегии инкрементальной интеграции, такие как Merge Early и Часто и их варианты, представляют собой форму управления рисками, которая пытается избавиться от риска на ранних этапах жизненного цикла, когда есть больше времени для реагирования на него. Регулярность ритма между интеграциями рассматривается [Booch], [McCarthy] и [McConnell] в качестве ведущего показателя здоровья проекта (например, «пульс» или «сердцебиение»).  
   
  Мало того, что ранняя и частая интеграция раскрывает риск раньше и в меньших «кусках», она также сообщает об изменениях между товарищами по команде ...

• 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://simpleprogrammer.com/2010/06/07/simple-branching-strategy-part-2-implementation/
      ... довольно подробный обзор ...

• http://www.codelathe.com/blog/index.php/2009/07/02/a-svn-branching-strategy-that-works/
  ... Наконец, помните, что не существует идеальной стратегии ветвления и слияния. Это в значительной степени зависит от вашей уникальной среды разработки ...

• http://blog.perforce.com/blog/?cat=62
  ... В худшем случае вы вводите проблему "семантического слияния", когда результат автоматического слияния неверен, но компилируется нормально и проходит мимо тестирование, возможно, даже длится достаточно долго, чтобы быть видимой клиентом ошибкой. Ик!  
   
  Добавляя оскорбление к травме, поскольку они могут дольше избежать обнаружения, проблемы с семантическим слиянием труднее исправить позже, поскольку изменение больше не является свежим в сознании разработчика, который создал это изменение. (Обычно лучше объединить изменения вскоре после их внесения, в идеале разработчиком, который инициировал изменение, если это целесообразно) ...

  • http://blog.perforce.com/blog/?p=1635
    Примечание. Рекомендуемая политика выглядит аналогично ветви разработки, как это определено в http://www.infoq.com/articles/agile-version-control#q11 и http : //msdn.microsoft.com/en-us/library/bb668955.aspx
  • Объяснение модели продвижения: http://www.perforce.com/perforce/papers/life.html

• https://stackoverflow.com/questions/34975/branching-strategies
  Члены сообщества делятся различным опытом в различных проектах с использованием различных стратегий ветвления. Нет согласованного консенсуса по «лучшему» или «худшему».

  • http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf
    «классическое» чтение - объясненная терминология, такая как Mainline Model , Codeline и т. д.

• http://www.stickyminds.com/s.asp?F=S16454_COL_2
  По существу, краткое изложение материала, представленного в http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf

  • http://www.stickyminds.com/s.asp?F=S16511_COL_2
    ... Существует три распространенных подхода к решению, когда и как разветвляться:
    • Создайте ветвь релиза, когда вы «полностью готовы», и планируйте исправлять проблемы, возникающие в последнюю минуту в этой строке кода. В этом случае ветвь релиза на самом деле представляет собой «строку кода подготовки к выпуску», как описано в шаблонах управления конфигурацией программного обеспечения , так как вы ожидаете, что еще предстоит проделать работу.
    • Измените свой стиль работы, чтобы избежать окончательной интеграции, отработки активной линии разработки.
    • Ветка для новой работы путем создания ветки задач и объединения этой работы в активную линию разработки после завершения выпуска.
      ... Обоснованием ветвления является изоляция кода в конце выпуска, чтобы он мог стабилизироваться. Изоляция посредством ветвления часто маскирует проблему качества, которая в конечном итоге проявляется в дополнительных затратах на поддержание параллельных потоков перед выпуском продукта. Ветвление легко. Скорее, это сложное объединение и когнитивные издержки понимания того, как происходят изменения между ветвями, поэтому важно выбрать процесс, который минимизирует стоимость ветвления и объединения ...

• http://nvie.com/posts/a-successful-git-branching-model/ Git-ориентированная стратегия.
  ... Мы считаем origin / master основной ветвью, где исходный код HEAD всегда отражает состояние готовности к работе .  
   
  Мы считаем, что origin / development является основной ветвью, где исходный код HEAD всегда отражает состояние с последними внесенными изменениями разработки для следующего выпуска. Некоторые называют это «интеграционной ветвью». Это где любые автоматические ночные сборки строятся из ....

  • Несколько напоминает стратегию ветки разработки , определенную в http://www.infoq.com/articles/agile-version-control#q11 и http://msdn.microsoft.com/en-us/library/bb668955.aspx

• 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://www.eclipse.org/articles/article.php?file=Article-BranchingWithEclipseAndCVS/article1.html
  • http://www.eclipse.org/articles/article.php?file=Article-BranchingWithEclipseAndCVS/article2.html

• http://learnsoftwareprocesses.com/2007/12/29/common-branching-strategies/
  ... Вот некоторые из распространенных моделей ветвления:  

  1. Модель ветвления за выпуском. Одной из наиболее распространенных стратегий ветвления является согласование веток с выпусками продукта. Филиал содержит все ресурсы для разработки программного обеспечения для одного выпуска. Иногда обновления должны быть объединены из одного выпуска в другой, но обычно они никогда не объединяются. Филиалы будут прекращены после выхода релиза.  
  2. Ветвление на продвижение. Другой очень распространенный подход - это согласование веток с уровнями продвижения программного обеспечения. Конкретная версия разработки разветвляется на ветку Test, в которой выполняется вся интеграция и тестирование системы. После завершения тестирования ресурсы для разработки программного обеспечения разветвляются на производственную ветвь и в конечном итоге развертываются.  
  3. Ветка на задачу. Чтобы избежать дублирования задач (или действий) и снижения производительности, вы можете изолировать их в отдельной ветке. Имейте в виду, что это краткосрочные ветви, которые должны быть объединены, как только задача будет выполнена, так как в противном случае требуемые усилия по объединению могут превысить преимущества в производительности, связанные с их созданием.  
  4. Ветвь на компонент: вы можете выровнять каждую ветвь в соответствии с архитектурой системы. В этой стратегии вы разветвляете отдельные компоненты (или подсистемы). Затем каждая группа, разрабатывающая компонент, решает, когда объединить свой код обратно в линию разработки, которая служит в качестве ветви интеграции. Эта стратегия может хорошо работать, если имеется системная архитектура и отдельные компоненты имеют четко определенные интерфейсы. Тот факт, что вы разрабатываете компоненты в филиалах, позволяет более детально контролировать ресурсы разработки программного обеспечения.  
  5. Ветвление на одну технологию: еще одна стратегия ветвления, согласованная с архитектурой системы. В этом случае ветви ориентированы на технологические платформы. Общий код управляется в отдельной ветке. Из-за уникальной природы активов разработки программного обеспечения, управляемых в филиалах, они, вероятно, никогда не сливаются ...

• http://msdn.microsoft.com/en-us/library/bb668955.aspx
  ... См. рекомендации по ветвлению и слиянию в «Руководстве по управлению исходным кодом» в этом руководстве для получения краткого описания рекомендаций по ветвлению и слиянию. ... При ветвлении учитывайте следующее:

  • Не выполняйте ветвление, если вашей команде разработчиков не нужно одновременно работать с одним и тем же набором файлов. Если вы не уверены в этом, вы можете пометить сборку и создать ветку из этой сборки на более позднем этапе. Объединение веток может быть трудоемким и сложным, особенно если между ними происходят значительные изменения.
  • Структурируйте деревья ветвей так, чтобы вам нужно было объединяться только по иерархии (вверх и вниз по дереву ветвей), а не по иерархии. Ветвление по всей иерархии требует использования безосновательного слияния, которое требует более ручного разрешения конфликтов.
  • Иерархия ветвлений основана на родительских ветвях и дочерних ветвях, которые могут отличаться от физической структуры исходного кода на диске. При планировании слияний учитывайте логическую структуру ветвей, а не физическую структуру на диске.
  • Не разветвляйтесь слишком глубоко. Поскольку для выполнения каждого конфликта слияния и разрешения конфликтов требуется время, глубокая структура ветвления может означать, что изменения в дочерней ветви могут занять очень много времени для распространения на основную ветвь. Это может негативно повлиять на графики проекта и увеличить время на исправление ошибок.
  • Ветка на высоком уровне и включает конфигурационные и исходные файлы.
  • Развивайте свою ветвящуюся структуру со временем.
  • Для слияния требуется, чтобы один или несколько разработчиков выполнили слияние и разрешили конфликты. Объединенный источник должен быть тщательно протестирован, потому что нередко принимаются неверные решения о слиянии, которые могут дестабилизировать сборку.
  • Объединение по иерархии ветвей особенно сложно и требует от вас вручную обрабатывать многие конфликты, которые в противном случае могли бы быть обработаны автоматически.  
    Решение о создании ветви может быть сведено к тому, будет ли стоимость слияния конфликтов в реальном времени выше, чем накладные расходы на слияние конфликтов между ветвями ...

• http://kashfarooq.wordpress.com/2009/11/23/bazaar-branching-strategy-with-a-subversion-trunk/

  • http://kashfarooq.wordpress.com/2010/12/16/bazaar-branching-strategy-with-a-subversion-trunk-revised/
  • http://kashfarooq.wordpress.com/2009/11/02/using-bazaar-feature-branches-with-a-subversion-trunk/
  • http://kashfarooq.wordpress.com/2009/09/08/bazaar-or-git-moving-away-from-subversion/
    ... Любая из этих жалоб Subversion звучит знакомо?
    • Вы случайно указали, что «вам нужно запустить обновление». Затем вы делаете обновление - которое занимает целую вечность. И, наконец, вы видите, что не было никаких изменений, которые нужно было загружать.
    • Вы случайно получаете указание, что «вам нужно запустить очистку».
    • У вас огромные проблемы слияния. Например, вы используете ReSharper для переименования класса, а некоторые еще обновили этот класс за это время. Затем вы видите ужасную ошибку конфликта дерева (дрожь). Или, что еще хуже, вы переименовываете все пространство имен и папку (двойная дрожь). Теперь вы действительно в мире боли.
    • Ваши слияния имеют тенденцию быть все более и более ручным. Вам часто приходится использовать WinMerge, потому что Subversion не имеет понятия.
    • Вы часто ждете, пока Tortoise обновит / проверит наличие каких-либо изменений.  
       
      У меня есть хранилище Subversion на USB-накопителе. Я получаю конфликты деревьев и сливаю проблемы с этим, и я единственный пользователь!  
       
      Основная проблема - слияние ...  
       
  • "Subversion Sucks" звучит знакомо. Время слушать Джоэла и Линуса ?

• 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://www.zeroturnaround.com/blog/continuous-integration-and-feature-branches/ более детальный анализ взаимодействия ветвления с непрерывной интеграцией, основанный на конкретном опыте с Hudson / Jenkins - вместе с парой полезных ссылок
    . Моим величайшим открытием было то, что, хотя КИ касается фиксации, подталкивания и получения обратной связи (т. Е. Кластер КИ предоставляет вам обратную связь, которую ваша рабочая станция никогда не сможет дать вам за такое же время), истинный пуристический КИ на самом деле имеет еще одно требование - что команда должна работать на той же базовой линии ...
    Использованные материалы
    • Советы и рекомендации по нескольким ветвям - публикация в списке Дженкинса
    • Можно ли обрабатывать несколько веток, где некоторые задания должны выполняться на каждой без дублирования - публикация в список Jenkins
    • Параллельная разработка с ветвями - публикация в список Jenkins
    • Настройте или создайте задание Hudson автоматически - stackoverflow.com
    • Непрерывная интеграция с разработкой нескольких филиалов - stackoverflow.com
    • Обработка нескольких ветвей в непрерывной интеграции - stackoverflow.com
    • Непрерывная интеграция - Мартин Фаулер
    • Непрерывная интеграция - Википедия

• 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, и объединяться с транком только при разумной сборке твердое вещество?

  • ... Ствол - это то место, где должно происходить текущее развитие. У вас действительно не должно быть проблем с «сломанным» кодом, если все проверяют свои изменения перед их фиксацией. Хорошее практическое правило - обновлять (получать весь последний код из репозиториев) после того, как вы закодировали свои изменения. Затем соберите и проведите несколько юнит-тестов. Если все построено и работает, вам следует проверить это ...
  • ... Нету багажник не лучшее место. В нашей организации мы всегда придерживаемся такого подхода: Trunk содержит код выпуска, поэтому он всегда компилируется. С каждым новым выпуском / вехой мы открываем новую ветку. Всякий раз, когда разработчик владеет элементом, он / она создает новую ветвь для этой ветки выпуска и объединяет ее в ветку выпуска только после тестирования. Ветвь релиза объединяется в транк после тестирования системы ...

• 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

  • Обратите внимание, что в настоящее время проект использует нестабильную модель ствола с ветвями релиза:
  • «Работа по разработке выполняется на магистрали SVN ... Существуют« ветки релизов »SVN, например, forrest_07_branch». ( руководство проекта )
  • «Создание пакетов-релизов-кандидатов ... 17. Создание ветки обслуживания в SVN ...» ( Как выпустить )

• Документы о ветвлении CVS O'Reilly:
  http://commons.oreilly.com/wiki/index.php/Essential_CVS/Using_CVS/Tagging_and_Branching#Basically_stable
  

  • ... Принципиально стабильная ветвление утверждает, что ствол должен содержать данные проекта, которые всегда близки к готовности к выпуску ... ... Более мягкие варианты этой философии позволяют объединить все, что проходит модульное тестирование разработчика, с багажник. Такой непринужденный подход требует, чтобы кандидат на релиз был разветвлен и прошел полный анализ качества перед публикацией ...
  • ... Принципиально нестабильная философия утверждает, что транк должен содержать самый последний код, независимо от его стабильности, и что кандидаты на выпуск должны быть разветвлены для обеспечения качества.
     
     
    ... Более мягкие вариации также позволяют создавать ветки для экспериментального кода, рефакторинга и другого кода для особых случаев. Объединение филиала обратно в ствол осуществляется менеджерами филиала. ...
    • Примечание выше ресурс не появился ни в одном из выполненных мной поисков (рекомендации, связанные с CVS, больше не популярны?)

• Лучшие практики в SCM (статья о выполнении) по адресу
  http://www.perforce.com/perforce/papers/bestpractices.html
  ... шесть общих областей развертывания SCM и некоторые грубые лучшие практики в каждой из этих областей. В следующих главах объясняется каждый элемент ...
  Рабочие пространства, Строки кода, Ветвление, Распространение изменений, Сборки, Процесс ...

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

Филиалы - самый простой способ достичь этого.

Хотя хорошо бы сократить жизненный цикл веток и избегать работы с одним и тем же модулем в двух ветвях одновременно - тогда у вас не возникнет проблем с конфликтами \ слиянием.

Но в последнее время я вижу все больше и больше сторонников идеи не создавать ветки, так как становится все труднее практиковать непрерывную интеграцию, непрерывную доставку и т. Д.

Ну это сделать более трудным практиковать непрерывную интеграцию, непрерывную доставку, и т.д. для вас конкретно?

Если нет, то я не вижу причин менять ваш способ работы.

Конечно, хорошей практикой является следить за тем, что происходит и как развиваются нынешние лучшие практики. Но я не думаю, что нам нужно отказываться от наших процессов / инструментов / еще чего-то только потому, что X (и / или Y и / или Z) сказали, что они больше не причуды :-)

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

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

С другой стороны, я мало использовал git, и, возможно, именно ответ на эти ответы оказал влияние на эти ответы - я понимаю, что ветвь / слияние дано в git, потому что это так просто.

Да, вы должны использовать ветки, чтобы изолировать любые (хотя бы средние) усилия по разработке. Смотрите « Когда вы должны разветвляться? ».

Проблема в том, чтобы использовать ускоренные слияния (которые включают в себя историю ветвлений внутри другого), при условии, что вы сначала уничтожите все «промежуточные фиксации контрольной точки» (которые могут быть проблемой в случае отката или git bisect).
См. « Понимание рабочего процесса Git », чтобы отличить частные ветки (не предназначенные для отправки) от общедоступных ветвей, которые будут завершены слияниями ff (ускоренные слияния) при условии, что вы выполните необходимую очистку в ветке, которую вы объединяете ,
Смотрите также « Почему git использует ускоренное слияние по умолчанию? ».

Вы должны обязательно использовать ветки. В этом есть ряд сильных сторон.

• Вы можете проверять свою работу на ходу, если вас беспокоит потеря работы из-за сбоя HD, потери ноутбука и т. Д., И это не сломает основной КИ.
• Вы все еще можете сделать CI, просто настройте свой собственный локальный CI, чтобы наблюдать за вашей веткой.
• Если функция внезапно блокируется (этого никогда не происходит), вы можете просто оставить ее.

Слишком трудно никогда не оправдание. Всегда нужно больше усилий, чтобы сделать это правильно.

Если две команды работают в своей собственной ветке, они не увидят изменений другой команды, даже если обе интегрируют masterветку. Это будет означать, что их ветки разработки будут расходиться, и если одна из команд сойдет с ней master, другая команда должна отменить множество изменений.

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

• Рефакторинг Backport

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

• Используйте функциональные переключатели

Мы только что прошли через это (снова). Сначала у нас была целая дискуссия по GIT / SVN, которая привела нас к стратегиям ветвления в целом.

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

Разветвление и слияние сложно. Особенно если у вас есть бизнес, который регулярно меняет свое мнение, требует откатов и т. Д.

Это предложение может спасти вам жизнь: то, что находится в SCM, не то же самое, что в ваших встроенных артефактах!

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

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

Модуль А находится в стадии разработки и входит в ваш еженедельный выпуск. Модуль B - это модуль A, но с проектом X в нем, и он работает в той же ветке, но не встроен в ваш выпуск. В какой-то момент в будущем вы захотите выпустить проект X. Таким образом, вы скажете своему инструменту сборки прекратить вставлять модуль A и начать вставлять модуль B.

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

Но есть твой ответ.

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

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

Я рекомендую такую ​​схему веток:

релиз - тест - разработка

Затем от разработки, ветки по разработчикам и / или по функциям.

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

Такая схема действительно хорошо работает со многими разработчиками и несколькими проектами в одной кодовой базе.

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

ИМХО, тогда ответ ДА . Мы все еще должны использовать ветвление.

Процесс в моей организации широко использует филиалы и (процесс, который немного похож) непрерывную интеграцию.

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