Відгалужувати чи не розгалужувати?

До недавнього мого робочого процесу в розробці було таке:

1. Отримайте функцію від власника продукту
2. Зробіть відділення (якщо функція більше 1 дня)
3. Реалізуємо це у філії
4. Об’єднати зміни від головної гілки до моєї гілки (щоб зменшити конфлікти під час зворотного злиття)
5. Об’єднати мою гілку назад до основної гілки

Іноді були проблеми зі злиттям, але взагалі мені це сподобалось.

Але останнім часом я бачу все більше прихильників ідеї не створювати гілки, оскільки це ускладнює практику безперервної інтеграції, безперервної доставки тощо. І це особливо смішно звучить від людей з розподіленим фоном VCS, які так багато говорили про великі злиття реалізації Git, Mercurial тощо.

Тож питання полягає в тому, чи варто сьогодні використовувати гілки?

Якщо ви не всі працюють з того ж робочого дерева, ви які з гілками, їх називають ви це чи ні. Кожен раз, коли розробник перевіряє своє робоче дерево, він створює окрему локальну гілку розвитку, і кожен раз, коли він перевіряє, він робить злиття. Для більшості команд питання не в тому, якщо ви використовуєте гілки, а скільки їх і з якою метою ?

Єдиний спосіб зробити справді "безперервну" інтеграцію - це кожен працювати з одного робочого дерева. Таким чином, ви відразу знаєте, чи ваші зміни негативно впливають на чужі. Очевидно, що це неможливо. Вам потрібна певна ступінь ізоляції у гілці, щоб досягти чогось, навіть якщо ця гілка є лише вашим місцевим робочим каталогом. Що потрібно - це належний баланс інтеграції та ізоляції.

З мого досвіду, використання більшої кількості гілок покращує ступінь інтеграції, оскільки інтеграція робиться саме з людьми, яким це потрібно зробити, а всі інші можуть легше відокремити непов'язані проблеми за потребою.

Наприклад, я провів останній день, відстежуючи три нещодавно введені помилки, пов’язані з інтеграцією в нашій збірці, які блокували мою "справжню" роботу. Зробивши належну ретельність у повідомленні цих помилок людям, які потребують їх виправлення, я тепер повинен просто чекати, поки вони закінчуться, щоб продовжити свою роботу? Звичайно, ні. Я створив тимчасову локальну гілку, яка повертає ці зміни, щоб я міг мати стабільну базову лінію, з якою я можу працювати, поки отримувати останні зміни від висхідного потоку.

Без можливості зробити нову гілку для цієї мети, я був би зведений до одного з трьох варіантів: або відновити зміни в центральному репо, вручну підтримувати патчі, які повертають їх у моєму робочому дереві, і намагаюся не випадково перевірити їх у або вийти на версію до появи цих помилок. Перший варіант, ймовірно, може порушити якусь іншу залежність. Другий варіант - це велика робота, тому більшість людей обирають третій варіант, який по суті заважає вам робити більше інтеграційних робіт, поки не будуть виправлені раніше знайдені помилки.

Мій приклад використовував приватну локальну гілку, але той самий принцип стосується і спільних гілок. Якщо я поділяю свою галузь, то, можливо, ще 5 людей можуть продовжувати виконувати свої основні завдання замість виконання надмірної інтеграційної роботи, таким чином, в сукупності виконується більш корисна інтеграційна робота. Проблема з розгалуженням і постійною інтеграцією полягає не в тому, скільки у вас є гілок, а в тому, наскільки часто ви їх об’єднуєте.

питання полягає в тому, чи варто сьогодні використовувати гілки?

Приблизно півроку тому мені було призначено виконати дослідження, щоб відповісти на це питання. Ось резюме на основі вивчених посилань (перелічено нижче)

• немає загально узгодженої "найкращої" стратегії розгалуження, застосовної до будь-якого проекту
  • Більшість ресурсів, схоже, згодні з тим, що вибір продуктивної стратегії залежить від конкретних особливостей проекту
  • бічна записка. Виходячи з вищесказаного, схоже, що будь-які зміни в стратегії розгалуження проекту потрібно перевірити, виміряти та порівняти з іншими тестованими варіантами
• Популярна думка, що об'єднання з Subversion вимагає великих зусиль. Усі, хто порівнював SVN та Git, відзначають, що злиття критично простіше з Git
• Важливим фактором, здається, є виробничі випуски походять із стовбура чи гілок. Командам, які роблять prod випуски з магістралі (які, здається, не дуже популярний спосіб), по суті заборонено використовувати нестабільну стратегію магістралі . Команди, які роблять prod випуски з гілок, мають більше варіантів розгалуження.
• популярні стратегії здаються стабільним магістральним, нестабільним магістральним і розвивальним (інтеграційним) відділенням

посилання

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

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

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

  ... Часта, поступова інтеграція є одним із знаків успіху, і її відсутність часто є характеристикою невдач. Сучасні методи управління проектами, як правило, уникають суворих моделей водоспадів та охоплюють спіралеподібні моделі ітеративного / поступового розвитку та еволюційного забезпечення. Стратегії поступової інтеграції, як-от Раннє і часто злиття та його варіанти, є формою управління ризиками, яка намагається вивести ризик на початку життєвого циклу, коли на це більше часу відповісти. Регулярність ритму між інтеграціями розглядають [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 процесу, але я покажу тобі, як щоб змусити його працювати ...  
   
  ... Якби мені довелося базувати свої міркування на одному твердому аргументі, це було б значенням безперервної інтеграції. Я обговорював цінність ІС та найкращі практики в минулому. Я досить великий прихильник КІ ...  
   
  ... Ви справді повинні задати собі запитання тут: "Чи все, що ви накладаєте на себе, виконуючи ваші складні стратегії розгалуження та об'єднання, призводять до справжнього значення, яке не існує для більш простої стратегії?" ...  
   
  .. .Стратегія, яку я ефективно використовував у минулому і розроблялася з часом. Я коротко підсумую тут.

  • Кожен працює з багажника.
  • Відділіться, коли ви випустите код.
  • Відключіть випуск, коли вам потрібно створити виправлення помилок для вже випущеного коду.
  • Відділення для прототипів.
    ...
    • 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
    "класичне" читання - пояснено термінологією, як основна модель , кодова лінія тощо

• 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.
  ... Ми вважаємо , походженням / господаря бути основною галуззю , де вихідний код КЕРІВНИКА завжди відображає готове стан.  
   
  Ми вважаємо походження / розробку головною гілкою, де вихідний код 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 є безкоштовними для всіх. Перевага цієї системи полягає в тому, що вона проста - нікому не потрібно дізнаватися про розгалуження або злиття. Недоліком є ​​те, що код магістралі часто нестабільний або непридатний для використання. Інші проекти вкрай використовують гілки: жодна зміна ніколи не здійснюється безпосередньо магістралі. Навіть найтривітніші зміни створюються на короткочасній гілці, ретельно переглядаються і зливаються в стовбур. Потім гілку видаляють. Ця система гарантує надзвичайно стабільний та зручний багажник у будь-який час, але ціною величезноюобробляти накладні витрати.  
   
  Більшість проектів мають підхід в середині дороги. Вони зазвичай наполягають на тому, що / магістраль збирається та проходить регресійні тести в усі часи. Гілка функції потрібна лише тоді, коли для зміни потрібна велика кількість дестабілізуючих комітетів. Добре правило - задати це питання: якби розробник працював цілими днями в ізоляції, а потім здійснив велику зміну всі відразу (щоб / багажник ніколи не дестабілізувався), чи було б це занадто великою зміною для перегляду? Якщо відповідь на це запитання - «так», зміна має бути розроблена на функції функції. Оскільки розробник здійснює додаткові зміни у галузі, вони можуть бути легко переглянуті однолітками.  
   
  Нарешті, виникає питання про те, як найкраще утримувати гілку функції в "синхронізації" зі стовбуром у міру прогресування роботи. Як ми вже згадували раніше, існує великий ризик працювати у філії тижнями чи місяцями; Зміни стовбура можуть продовжуватись розливатися до того моменту, коли дві лінії розвитку настільки сильно відрізняються, що це може стати кошмаром, який намагається злити гілку назад до стовбура.  
   
  Такої ситуації найкраще уникати шляхом регулярного злиття змін стовбура до гілки. Складіть політику: один раз на тиждень об'єднуйте варті зміни стовбура минулого тижня у галузь ...

• http://thedesignspace.net/MT2archives/000680.html
  ... Цей розділ підручника CVS Eclipse базується на статті Пола Глізена на веб-сайті 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://learnsoftwareprocess.com/2007/12/29/common-branching-strategies/
  ... Ось деякі поширені моделі розгалуження:  

  1. Модель відгалуження до випуску: Однією з найпоширеніших стратегій розгалуження є вирівнювання гілок з випусками продуктів. Філія зберігає всі засоби розробки програмного забезпечення для одного випуску. Іноді оновлення потрібно об'єднувати від одного випуску до іншого, але вони зазвичай ніколи не зливаються. Гілки будуть припинені, коли випуск буде звільнено.  
  2. Відділення за акцією: Ще один дуже поширений підхід - узгодження гілок із рівнями просування програмних активів. Конкретна версія розробки розгалужена на тестову гілку, в якій виконується вся інтеграція та тестування системи. Після завершення тестування активи розробки програмного забезпечення розгалужуються у виробничій галузі та врешті-решт розгортаються.  
  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-revision/
  • 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 не має поняття.
    • Ви часто чекаєте, коли Черепаха оновлюється / перевіряє на зміни / що-небудь.  
       
      На моєму USB-накопичувачі є сховище для підривної роботи. У мене виникають конфлікти з деревами і зливаються з цим проблеми, і я єдиний користувач!  
       
      Основна проблема - це злиття ...  
       
  • "підривна смоктання" звучить звично. Час слухати Джоела та Лінуса ?

• http://social.msdn.microsoft.com/Forums/en/tfsversioncontrol/thread/f127676c-8f05-410c-9a30-0eb43a26a9fa
  обговорення кращої практики для випуску стратегії гілки ізоляції у випадку розвиваються систем.

• http://branchingguidance.codeplex.com/
  "Посібник з розгалуження сервера корпорації Microsoft Team Foundation" - величезний і детальний документ з рекомендаціями, пристосованими до різних проектів: тут розміщена HTML версія . Доводить, що Microsoft не вірить у стратегії розгалуження wrt одного типу, що підходить для всіх.

• https://stackoverflow.com/questions/597707/best-branching-strategy-when-doing-continuous-integration
  Яку найкращу стратегію розгалуження слід використовувати, коли ви хочете робити постійну інтеграцію? ... Відповідь залежить від розміру вашої команди та якості вашого джерела управління та здатності правильно об'єднати складні набори змін ...

  • http://www.zeroturnaround.com/blog/continuous-integration-and-feature-branches/ Детальніший аналіз розгалуження взаємодії з постійною інтеграцією, заснований на конкретному досвіді з Хадсоном / Дженкінсом - разом з парою корисних посилань
    .. . Моїм найбільшим відкриттям було те, що хоча CI збирається робити, натискати та отримувати зворотній зв'язок часто (тобто кластер CI надає вам зворотній зв'язок, що ваша робоча станція ніколи не може дати вам за той же час), справжній пуристський CI насправді має ще одну вимогу - що команді потрібно працювати на одній базовій лінії ...
    Використовувані матеріали
    • Кращі практики з декількох галузей - дописуйте до списку Дженкінса
    • Чи можна обробляти декілька гілок, де деякі завдання повинні виконуватись на кожній, не дублюючи - розміщуйте в списку Дженкінса
    • Паралельний розвиток з філіями - допис до списку Дженкінса
    • Налаштування або створення роботи Хадсона автоматично - 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 магістраль є рекомендованим місцем для основної розробки, і я використовую цю конвенцію для всіх моїх проектів. Однак це означає, що стовбур іноді нестабільний або навіть зламаний ... ... чи не було б краще робити "дику розробку" на такій гілці, як / гілка / dev, і зливатися лише з магістральним, коли збірка розумно твердий?

  • ... Стовбур - це місце, де має відбуватися постійний розвиток. У вас дійсно не повинно виникнути проблем із "зламаним" кодом, якщо кожен перевіряє свої зміни, перш ніж зробити їх. Добре правило - зробити оновлення (отримати весь останній код з репостів) після того, як ви зашифрували свої зміни. Потім складіть і зробіть тестування. Якщо все створюється і працює, вам слід добре перевірити це ...
  • ... Нічний багажник - не найкраще місце. У нашій організації ми завжди дотримуємось такого підходу: Trunk містить код випуску, тому він завжди компілюється. З кожним новим випуском / віхою ми відкриваємо нове відділення. Щоразу, коли розробник володіє елементом, він / вона створює нову гілку до цієї гілки випуску та об’єднує її у гілку випуску лише після її тестування. Гілка випуску об'єднується в магістраль після тестування системи ...

• http://blog.yclian.com/2009/03/working-on-branches-and-stable-trunk.html
  ... Раніше я працював на магістралі, оскільки для всіх проектів, над якими я працював, це я або був єдиний розробник або команда гарантували, що всі реєстрації коду пройшли місцеві тести. Інакше ми створили (ми все ще) гілки для виправлення помилок, великий код нових функцій тощо.  
   
  Близько 2 місяців тому я провів короткий сеанс git з Камалем, і він поділився зі мною ідеєю історії / гілки . І коли моя команда почала зростати з більшою кількістю хлопців-розробників, я відчував потребу заохочувати більше розгалуження, і тепер це стало правилом. Для проекту з автоматизованими тестами, визначеними за допомогою встановленого інтерфейсу, гарантується стабільний магістраль, і ця практика може дуже добре вписатися в нього.  
   
  Ми не використовуємо git, але Subversion, тому що так ми почали, і нам все ще зручно з цим зараз (більшість часу) ...

• http://www.ericsink.com/scm/scm_branches.html
  Це частина онлайн-книги під назвою Control Source HOWTO , посібник з передового досвіду управління джерелами, управління версіями та управління конфігурацією ...  
   
  ... Краще відділення Еріка Практика ... Зберігайте "в основному нестабільний" багажник. Робіть свій активний розвиток в магістралі, стабільність якої зростає по мірі наближення до випуску. Після відправки створіть відділення технічного обслуговування і завжди тримайте його дуже стабільним ...  
   
  ... У наступному розділі я детально розгледімо тему об'єднання гілок ...

• http://marc.info/?l=forrest-dev&m=112504297928196&w=2
  Початкова пошта теми, що обговорює стратегії розгалуження для проекту Apache Forrest

  • Зверніть увагу, що зараз, здається, проект використовує нестабільну модель магістралі з гілками випуску:
  • "Робота з розробки виконується на магістралі SVN ... Є" гілки випуску "SVN, наприклад, forrest_07_branch." ( керівництво проектом )
  • "Створення пакетів кандидатів до випуску ... 17. Створіть відділення технічного обслуговування у SVN ..." ( Як випустити )

• Документи з розгалуженнями O'Reilly CVS:
  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, тому що це так просто.

Так, вам слід використовувати гілки для ізоляції будь-яких (принаймні середніх) зусиль з розвитку. Див. " Коли ви маєте відділитись? ".

Проблема полягає в тому, щоб скористатися швидкими злиттями вперед (які включають історію філій у межах іншого), за умови, що ви скасуєте спочатку всі "проміжні контрольні пункти" (що може бути проблемою у випадку відкату або git bisect).
Див. Розділ " Розуміння робочого процесу Git ", щоб відрізнити приватні гілки (не призначені для витіснення) від публічних гілок, які будуть завершені ff злиттями (швидкі злиття вперед), за умови, що ви зробите необхідне очищення всередині гілки, яку ви об'єднуєте. .
Дивіться також " Чому git використовує швидке злиття вперед за замовчуванням? ".

Вам слід абсолютно використовувати гілки. Для цього є ряд сильних сторін.

• Ви можете перевірити свою роботу, якщо їдете, якщо вас турбує втрата роботи через поломку HD, втрата ноутбука тощо, і це не порушить основний CI.
• Ви все одно можете робити CI, просто налаштуйте свій власний локальний CI для перегляду вашого відділення.
• Якщо функція раптово перестає бути призупиненою (що ніколи не відбувається), ви можете просто припаркувати її.

Занадто важко - це ніколи не привід. Завжди потрібно більше зусиль, щоб зробити це правильно.

Якщо дві команди працюють над власною гілкою, вони не побачать змін іншої команди, навіть якщо обидві інтегрують masterгілку. Це означатиме, що їх галузі розвитку розійдуться, і якщо одна з команд об'єднається master, інша команда повинна змінити багато змін.

Тож навіть якщо у вас є гілки для особливостей, я б закликав вас зробити «репортажі» всіх переробників до головної гілки та зберегти гілку лише для нових функцій.

• Реквізити заднім числом

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

• Використовуйте функціональні перемикачі

Ми щойно пережили це (знову). Спочатку ми провели всю дискусію щодо GIT / SVN, яка загалом привела нас до розгалуження стратегій.

Усі великі компанії використовують стратегію, засновану на магістральних системах, де всі працюють в одній галузі, і в цій галузі відбувається побудова і постійне інтегрування. Уникнення конфлікту здійснюється за допомогою модуляції коду, перемикання функцій та розумного інструментарію. Це звучить важко .. тому що це так. Але якщо ви ведете цю дискусію, це тому, що ви стали жертвою фантазії людей про розгалуження. Деякі стверджують, що вони використовують тут інструмент SCM із повністю механізмом розгалуження, що відповідає сумісним сарбанам-оклі, і все це геніально. Вони або брешуть, обманюють себе, або не працюють за тими ж масштабами системи, що і ви.

Розгалуження та злиття важко. Особливо, якщо у вас є бізнес, який регулярно передумує і вимагає відкотів тощо.

Це речення може врятувати ваше життя: Те, що є у СКМ, не те саме, що у ваших побудованих артефактах!

Якщо у вас виникають проблеми з розгалуженням, це тому, що ви неправильно використовуєте SCM. Ми всі робили це роками. У вас є система, де використовується СКМ, щоб визначити, що входить у вашу остаточну збірку.

Це не робота СКМ. SCM - це прославлений файловий сервер. Завдання визначення, які файли з SCM входять до вашої збірки, належить до вашої інструментальної збірки.

Модуль A працює над і надходить у ваш щотижневий випуск. Модуль B - це модуль A, але із проектом X у ньому, і над ним працює над тим же відділенням, але він не вбудовується у ваш реліз. В якийсь момент у майбутньому ви хочете випустити проект X. Отже, ви скажете своєму інструменту збирання припинити введення модуля A і почніть вводити модуль B.

З цього приводу буде дуже багато плачу та ламання рук. Що іфери, і загальне виття. Такий рівень емоцій, що оточує щось таке просте, як сховище файлів, яким би розумним він не був.

Але є ваша відповідь.

Основна проблема розгалуження - це труднощі зі злиттям назад в основну гілку, коли розвиток завершений. Злиття може бути ручним і схильним до помилок, тому його слід уникати більшу частину часу.

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

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

випуск - тест - розробка

Потім від розробки, галузі за розробником та / або за особливістю.

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

Така схема дуже добре працює з великою кількістю розробників і декількох проектів на одній кодовій базі.

Ми робимо використовувати гілки, але не на гранульованому рівні функції. Ми використовуємо гілки для кожного спринту. Розгалуження по суті не є поганою справою IMO, оскільки вона імітує концепцію SOC у функції або спринтерному шарі. Ви легко можете розпізнати та керувати, яка галузь належить до якої функції чи спринту.

ІМХО, тоді відповідь, ТАК . Нам все ж слід використовувати розгалуження.

Процес у моїй організації широко використовує гілки та (процес, який трохи нагадує) постійну інтеграцію.

На високому рівні, розробники не надто турбуються про об'єднання з основною лінією, вони просто зобов'язуються до галузі. (напів-) автоматизований процес перевіряє, які функції планується перейти в основну лінію, об'єднує ці гілки та створює продукт. Процес працює тому, що ми фактично інтегруємо цей процес злиття з трекера випусків, щоб інструмент побудови знав, які гілки об’єднати.