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

84

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

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

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

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

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

SiberianGuy
источник
2
Я уверен, что это правильная платформа для этого, но да, я бы сказал. Но, возможно, вам следует подумать о слиянии некоторых
наборов
1
Похоже, им нужны лучшие стратегии для слияния.
b01
1
Я всегда рассматривал все коммиты как слияние, даже если они были просто локальными или удаленными. Слияния из ветвей одинаковы, только большие наборы изменений, поэтому я не понимаю, какой аргумент в любом случае. Кто-нибудь выполнил какое-либо реальное профилирование производительности любого из этих методов, или это всего лишь предварительная оптимизация?
Tylermac
Я бы сказал, что ветки облегчили бы CI ...
tdammers
7
Пожалуйста, не пересылайте одну и ту же дословную публикацию на несколько сайтов Stack Exchange.
Адам Лир

Ответы:

64

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

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

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

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

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

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

Карл Билефельдт
источник
1
Если вы отмените нежелательные коммиты в вашей новой ветке, разве это не отменит их в главной ветке, когда вы слились с ней? Я бы лично переходил от точки до нежелательных изменений и выбирал те изменения, от которых я зависел, в новую ветку.
Энтони
@anthony Скорее всего, вы бы очистили свою историю (удалили возвраты) перед слиянием. Кто-то против переписывания истории, вероятно, лучше следовать вашему методу.
idbrii
Если вы убираете ветвление и переписывание истории, зачем вообще использовать Git?
Эвертон
80

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

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

  • нет общепринятой «лучшей» стратегии ветвления, применимой к любому проекту
    • большинство ресурсов сходятся во мнении, что выбор продуктивной стратегии зависит от конкретной специфики проекта
    • Примечание. Исходя из вышеизложенного, похоже, что любые изменения в стратегии ветвления проекта необходимо протестировать, измерить и сравнить с другими протестированными вариантами.
  • Распространено мнение, что объединение с 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://www.codelathe.com/blog/index.php/2009/07/02/a-svn-branching-strategy-that-works/
    ... Наконец, помните, что не существует идеальной стратегии ветвления и слияния. Это в значительной степени зависит от вашей уникальной среды разработки ...

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

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

  • 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://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/
    ... Вот некоторые из распространенных моделей ветвления:  

    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://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 и некоторые грубые лучшие практики в каждой из этих областей. В следующих главах объясняется каждый элемент ...
    Рабочие пространства, Строки кода, Ветвление, Распространение изменений, Сборки, Процесс ...

комар
источник
37
Я верю, что это самый длинный ответ, который я видел в любом вопросе об обмене стека!
Джон Фишер
2
@JohnFisher в соответствии с JIRA , тогда я потратил 6 часов на то, чтобы собрать и обобщить эти ссылки :)
комнат
2
Вам не хватает какой-то сводки, которая должна указывать, использовать ли новые ветки для новых функций. Ваш ответ - просто сумма ссылок на различные статьи - некоторые из них говорят об одном, а другие говорят об обратном. Ваш ответ довольно длинный, поэтому я, возможно, заблудился.
BЈовић
3
@ BЈовић резюме приводится в начале ответа: «нет общепринятой« наилучшей »стратегии ветвления, применимой к любому проекту. * большинство ресурсов сходятся во мнении, что выбор продуктивной стратегии зависит от специфики конкретного проекта »
комнат
2
дополнительное чтение: Google против разработки на основе соединительных линий Facebook «У них [Google и Facebook] нет боли слияния, потому что, как правило, разработчики не сливаются в / из филиалов. По крайней мере, до центрального репо-сервера это не так. На рабочих станциях разработчики могут сливаться с локальными ветвями и из них и перебазировать, когда что-то «сделано» возвращается в центральное хранилище ... »
gnat
7

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

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

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

Shaddix
источник
5

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

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

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

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

Петер Тёрёк
источник
Конечно, это так! Это вопрос приоритетов: ветвление (изоляция функций) по сравнению с простой интеграцией, доставкой и т. Д.
SiberianGuy
1
это просто вопрос инструмента CI, который вы используете. Что мешает вам делать сборки и "постоянно доставлять" из ветки?
Shaddix
@Shaddix, как правило, трудно доставить из филиала. Например, как бы вы доставили из функциональной ветви?
SiberianGuy
1
В чем проблема, если у вас весь исходный код разветвлен (как в DVCS)?
Shaddix
1
@Shaddix, чем больше разветвленного кода, тем больше конфликтов вы получите при слиянии
SiberianGuy
4

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

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

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

Билл К
источник
2
+1, Эти git'er Данс становится все более фанатичным о дискуссионном превосходстве мерзавца над другими установками управления версиями / CI.
maple_shaft
3

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

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

VonC
источник
2

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

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

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

Билл Липер
источник
2
Я хочу понизить это не потому, что я против ветвления, а потому, что вы предлагаете использовать их ВСЕ ВРЕМЯ.
maple_shaft
Где он это сказал, он это редактировал или что-то?
b01
настройте свой собственный локальный CI, чтобы наблюдать за вашей ветвью для коротких ветвей (2-5 дней), которые могут быть довольно непроизводительными. Там было сделано
комнат
1
Я отвечал на вопрос об использовании веток вообще или вообще никогда не использовал ветки. Как и в случае с любым правилом или политикой, здравый смысл должен вступить в игру. Я не сотрудничаю по многим своим проектам, но я все еще свободно использую ветки в основном для третьей упомянутой мной пули. Также, что касается первого пункта, сколько раз вы получали срочный запрос, чтобы получить какую-то функцию / исправление вживую, но затем вы входите, и у вас есть около 3 наполовину законченных функций в мастере.
Билл Липер
Это не делает CI. Я в CI выступаю за интеграцию - интеграцию работы всех разработчиков, т.е. слияние. Нет ничего плохого в том, чтобы запускать тесты локально для каждого коммита, но это то же самое
bdsl
2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ричард
источник
1

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

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

maple_shaft
источник
4
Похоже, вам нужна лучшая практика для разработки новых функций. Мне лично нравится строить свои проекты так, чтобы их было легко изолировать, как правило, в отдельном файле / классе / или как угодно. Таким образом, добавление или удаление кода не вызывает серьезных сбоев в доставке или проблем при объединении нового кода или извлечении старого кода. Это хорошо работает при разработке с несколькими разработчиками. Но я могу понять, работаете ли вы над проектом, который, возможно, не был начат вами, или у вас нет никакого реального мнения о том, как проект будет продолжаться.
b01
1
@ b01, вот и все. Никто не может придумать идеальный дизайн, когда требования идут вперед и назад и меняются быстрее, чем ребенок с СДВГ на трещине. В других случаях вы пытаетесь реорганизовать унаследованный код для улучшения дизайна, и такая ситуация время от времени возникает. Это не самая серьезная проблема, с которой может столкнуться команда, и намного лучше, чем в некоторых местах, где я работал, где даже если предложить рефакторинг на собрании, вас бьют насмерть бейсбольной битой, похожей на сцену из «Неприкасаемых».
maple_shaft
Совершенно не согласен. Если вы разделяете по качественным ветвям и часто объединяетесь (ежедневно это хорошо), то вы избегаете почти всех «ручных и подверженных ошибкам» слияний.
Пол Натан
@Paul, поверь мне, это не работает для всех проектов или технологий. Подумайте об общем XML-файле конфигурации, как в Struts, где каждый каждый погружается в него каждый день. Но нет, твой путь работает все время, и я полностью заслужил понижение. Благодарю.
maple_shaft
1
Мета-подсказка @maple_shaft, если вы рассмотрите теги (git) и опубликуете что-то, что типичный пользователь этих тегов посчитает отрицательным, ожидайте отрицательных голосов от облета. Flybys почти всегда является неоправданной реакцией на то, что тебя ранили тем или иным комментарием, который ты принимаешь лично Считайте, что это хорошо, потому что это повышает ваш представитель через крышу.
Билл К
1

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

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

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

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

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

Пол Натан
источник
0

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

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

Саид Нямати
источник
0

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

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

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