Як вибрати модель розгалуження в Git, Бібліотека програміста
Отже, ви хочете використовувати git для контролю версій вашого поточного чи майбутнього проекту, але ніяк не зрозумієте, з чого почати? Почніть із нашої статті.
Існує безліч способів застосування git у проекті, а також співпраці з іншими розробниками. Крім використання git для контролю версій коду вашого проекту його можна використовувати для координації того, як інші працюють над проектом. Найефективніше цього можна досягти, застосувавши якусь модель розгалуження. Workflow, тобто модель розгалуження в git це практика, що спрощує роботу над проектом. Її сенс у тому щоб організувати, додавання та публікацію змін у вихідному коді репозиторію. Найбільш ефективним для проектів є наявність віддаленого репозиторію. Модель розгалуження це не правило, яке потрібно слідувати, а скоріше путівник. Тому можете просто вибрати певні аспекти та поєднувати їх так, як вам потрібно. Для цієї статті припустимо, що ваша гілка це master і що ви знайомі з основними термінами git (гілка, коміт, злиття, pull request, patch, fork, репозиторій) або можете їх прогуглити. Тут кілька моделей розгалуження, які можна розглянути для використання у своєму проекті. Для кожної описано суть роботи та мету застосування.
Central Workflow
Репозиторій містить лише одну головну гілку master. Усі зміни комітуються до неї. Репозиторій може бути локальним, без віддалених копій або зберігатись віддалено, де він може бути клонований або запушений.
Коли використовувати
Ідеально підходить для одиночного проекту. У своєму проекті ви зможете використовувати цю модель, щоб бачити які зміни відбулися протягом процесу розробки. Після виконаної роботи ви комітитезміни так, що пізніше зможете повернутися до будь-якої попередньої версії. Також вона відмінно підійде для невеликих команд, які перейшли від syn до git.
Developer Branch Workflow
Коли використовувати
Feature Branch Workflow
У своїй простій формі репозиторій міг би мати основну гілку зі стабільним, доступним кодом та іншими гілками для різних фіч (або багів, або поліпшень), які можна було б інтегрувати в головну гілку. Тобто репозиторій матиме другорядну основну гілку (dev), яка зберігатиме тестований стабільний код для відправки користувачам, коли він буде злитий з master. У цьому випадку гілка з фічами буде злита з dev, а не з master.
Коли використовувати
Issue Branch Workflow
Дуже схожа на попередню модель з однією лише відмінністю. Гілки створюються із завдань у проектному трекері. Гілки можуть мати однакові назви id завдань. І тут лише одна гілка на завдання та одне завдання на гілку.
Коли використовувати
Найкраще підійде проектам, які керуються за якимось методом. Однак, незважаючи на це, найбільше підходить тим проектам, в яких фічі готуються не одним розробником. Наприклад, якби ви працювали над самим інтерфейсом, а інший розробник працював би над його іншим аспектом. Він може бути використаний в обох проектах, релізи яких виходять постійно або іноді.
Forking Workflow
Завдяки цій моделі доповнення проекту здійснюються шляхом створення розгалуження його репозиторію. Всі зміни фіксуються в будь-якій гілці репозиторію, а потім повертаються у вихідне сховище з запитом pull. Розробники матимуть доступ лише до читання у віддаленому репозиторії.
Коли використовувати
Найчастіше використовується у проектах з відкритимвихідним кодом та публічними репозиторіями. Кожен, хто може переглядати репозиторій, може зробити розгалуження. Доки вони можуть переглядати репозиторій їм не потрібен доступ для того, щоб внести зміни безпосередньо в репозиторій. Коли вони закінчили свою роботу, вони можуть зробити запит, який ви розглядатимете і вирішите, що ж з ним робити, інтегрувати, відмовити або просити доопрацювати до остаточного злиття з проектом.
Patch Workflow
Використовуючи цей підхід, розробники додають зміни до репозиторію разом із патчем — файлом, який містить усі зміни у репозиторії. Цей патч застосовується кимось, хто може безпосередньо писати репозиторій, наприклад maintainer/owner.
Коли використовувати
Використовується, якщо розробник не може безпосередньо писати в репозиторій, але має доступ до вихідного коду. Якщо, наприклад, ви поділилися кодом свого проекту з другом або він отримав доступ до віддаленого репозиторію. Після змін, які ви закоментували в їх копію вихідного коду створюється патч і відправляється вам. Ви застосовуєте їх до репозиторію, щоб оновити його. Також використовується тими, хто не є головним розробником проекту.
Ви можете знайти ще мільйон інших способів взаємодії в git або навіть ті, які були описані тут просто під іншими назвами. Тут лише кілька моделей. Решта залишається на вашу думку, вибрати одну з них або поєднувати кілька. Просто вибирайте та користуйтеся.