Стратегія розгалуження Git для довгого запуску невипущеного коду

У нашої команди, окрім окремих одиниць роботи (Історії), ми маємо довші теми роботи (билини). Кілька історій складають епос.

Традиційно у нас були спеціалізовані гілки для кожної історії, і ми об'єднували їх безпосередньо для освоєння, коли вони проходять QA. Однак ми хотіли б почати стримувати випуск завершених історій в епосі, поки Епік не буде визнаний "функцією завершеною". Ми могли б випустити ці функції у виробництво лише тоді, коли весь Epic закритий. Крім того, ми маємо нічний сервер побудови - ми хотіли б, щоб усі закриті Історії (включаючи ті, що є частиною неповних Epics) були автоматично розгорнуті на цей нічний сервер.

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

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

— Сітаті
джерело

Відповіді:

Проста пропозиція: не робіть цього.

гілки git не для довготривалих виделок коду, про що йшлося тут та https://blog.newrelic.com/2012/11/14/long-running-branches-considered-harmful/ . Гілки найкраще трактувати як перехідні речі, що використовуються для організації обмінів індивідуальним розробником щоденно. Тож якщо у них є ім’я, яке відповідає чомусь, менеджер проектів (не кажучи вже про кінцевого користувача) може піклуватися про те, чи ви робите щось не так.

Рекомендована практика полягає у використанні безперервної інтеграції із функціями перемикання функцій або абстрагуванням по гілці для того, щоб:

весь код інтегрований постійно (принаймні щодня, бажано частіше)
те, що розгортається, знаходиться під чітким контролем.

— сор
джерело

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

— Сітаті

Добре використовувати гілки для розробки коду, просто ніколи не використовуйте їх для зберігання коду. Тож якщо ви не впевнені, що завдання - це 30-хвилинне виправлення або 2-тижнева робота, тоді почніть на гілці. Як тільки ви дізнаєтесь, або злиття, або рефактор до абстракції / перемикання, потім злиття.

— soru

@Sitati: Я щойно об'єднав якийсь код, який був у відділенні функцій протягом останніх чотирьох місяців. Тим часом develми перейшли на CMake від Autotools, запровадили Travis CI і відновили код. Зрештою, було легше зрозуміти нову функцію та застосувати її вручну, develніж намагатися її об’єднати. У нас також були нові студенти-магістри, які розробили нову особливість у галузі, яку вони розгалужували, коли починали дисертацію. Через рік вони підштовхнули її, і не було зусиль, щоб повернути його назад, тому з кожним днем зливатися було важче.

— Мартін Удінг

Пов’язаній публікації в блозі зараз 5 років. Я ненавиджу перемикачі функції. Що поганого в розгалуженні довгострокового періоду, регулярному злитті назад у функціональну гілку від основного та доданні постійної інтеграції до довгострокової гілки функцій?

— Джейсон Келлі

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

— soru

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

напр.

У мене є функції A, B і C для v2 свого продукту. B і C пов'язані, я не хочу випускати B, якщо C також не закінчено.

У мене три диски, які працюють одночасно над функціями.

У мене встановлено дату виходу каменю D

B закінчений і об'єднаний, A закінчений і об'єднаний. C затриманий ... що робити ?!

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

Рішення - більш людське. Ви пропустили дату виходу, і її потрібно відсунути назад

— Еван
джерело

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

Розробка -> Нові речі, над якими працює
Майстер -> Готові речі, які потребують тестування Виробництво -> Речі, які були опубліковані до виробництва.

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

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

Через регулярні проміжки часу (залежить від проекту) я зливаю розробку назад у головний і починається цикл тестування. Якщо під час тестування з’являються якісь виправлення, вони робляться у головній гілці (підрозділ потім об'єднується) І розвиток може продовжуватися на головній галузі під час тестування.

У будь-який час майстер повинен бути об'єднаний у розвиток, а розвиток має бути об'єднаний у будь-яку з довгострокових підгалузей.

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

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

Моє звичайне дерево виглядає так

 LongTerm -> Development -> Master -> Production    
 LongTerm <- Development      |            |  
     |       Development -> Master         |  
 LongTerm <- Development -> Master         |  
             Development <- Master         |  
                            Master -> Production

Це моє загальне правило, що жодна зміна не повинна тривати більше кількох годин. Якщо це так, то його потрібно внести в менші зміни. Якщо це величезна функція (наприклад, перезапис UI), то це триває в довгостроковій перспективі, щоб нормальний розвиток може продовжуватися в той же час. Філії LongTerm, як правило, є лише локальними філіями, тоді як Development, Master та Production - віддалені гілки. Будь-які підрозділи також є лише локальними. Це забезпечує збереження сховища в чистоті для інших, не втрачаючи корисності git на довгостроковому наборі функцій.

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

— котейр
джерело

"За основними (довгостроковими) ознаками я створюю галузь з розвитку" - чи не слід створювати нові функції (розробки) гілки з виробничої галузі? Якщо галузь виробництва - це готовий до випуску код.

— роботрон

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

— coteyr

Але якщо відгалуження від dev і пізніше злиття назад не буде ця гілка (і, отже, освоєння і виробництво пізніше), то включить усі зміни, внесені іншими розробниками, аж до розгалуження? Деякі з цих змін можуть не мати затвердження якості. Можливо, йшлося про різні підходи до випуску управління.

— роботрон

Так, так і буде. Тести QA на конкретному SHA в майстер, але ви не можете затримати розробник за це.

— coteyr

"Тестування якості на конкретному SHA в майстер" -> QA перевіряє кожну нову функцію як окрему? Дозвольте мені запустити за вами типовий сценарій, з яким стикається моя команда: скажіть, у вас є два тривалі проекти на одній і тій же кодовій базі: Проект A перебуває в якості попереднього місяця і буде QA'd ще один місяць. Проект B розроблявся протягом останніх 6 місяців і зараз готовий до забезпечення якості. Проект A об'єднаний у головний і, безумовно, не готовий до виробництва через численні найтонші помилки правил бізнесу. Як ми працюємо з проектом B? A і B повинні бути протестовані разом, щоб перевірити на взаємодію (B не спричинить конфліктів під час злиття).

— роботрон