GitLab Flow

Це переклад досить важливою статті про GitLab Flow, альтернативу Git і GitHub flow. Стаття була написана в 2014, так що скріншоти встигли застаріти. Тим не менше сама стаття більш ніж актуальна, особливо якщо ви до цих пір йдіть на Git Flow. Нижче сама стаття:


Розгалуження і злиття гілок в git влаштовано набагато простіше, ніж в попередніх системах контролю версій, таких як SVN. Тому є багато способів організації командної роботи над кодом, і більшість з них досить гарні. Принаймні, вони дають багато переваг в порівнянні з тим, що було до git. Але сам по собі git — не срібна куля, і в багатьох командах організація робочого процесу з git має ряд проблем:
  • Не описаний точним чином весь робочий процес,
  • Вноситься непотрібна складність,
  • Немає зв'язку з трекером завдань (issue tracker).
Ми хочемо представити вам GitLab flow — чітко певний набір практик, що вирішує ці проблеми. Він об'єднує в одну систему:

Ця стаття описує всі аспекти GitLab flow, включаючи роботу з гілками, інтеграцію з завданнями, безперервну інтеграцію і розгортання. Її мета — допомогти новим командам перейти на git і відразу впровадити прості, прозорі та ефективні правила роботи з ним.
Four stages (working copy, index, local repo, remote repo) and three steps between them
У більшості систем контролю версій, щоб поділитися кодом з колегами, потрібно зробити одну дію — комміт в репозиторій. В git те ж саме відбувається в три етапи:
  1. Додати зміни з робочої області проекту в індекс (область підготовлених файлів, staging area);
  2. Зробити комміт на основі індексу;
  3. Запушить отримати віддалений репозиторій.
Освоєння цих дій — перший крок у вивченні git. Слідом йде робота з гілками.
Multiple long running branches and merging in all directions
Якщо не встановлювати ніяких правил роботи з гілками, в репозиторії починає рости ентропія:
  • З'являється багато довгоіснуючих гілок,
  • Вносяться зміни виявляються розмазаними по різних гілках,
  • Незрозуміло, звідки починати розробку нової фічі або звідки розгортати код на production.
Для вирішення цих проблем зазвичай впроваджується якась стандартна модель роботи, наприклад git flow або GitHub flow. Ми вважаємо, що у всіх цих моделей є потенціал для поліпшення, тому ми розробили GitLab flow.
Git flow і його обмеження
Git Flow timeline by Vincent Driessen, used with permission
Модель робочого процесу Git flow з'явилася однією з перших і стала досить широко відомою. Вона передбачає наявність основної гілки
master
, гілки для накопичених змін
develop
, а також окремих гілок для фіч, релізів і хотфиксов. Розробляються зміни мержатся
develop
, звідти в релизные гілки, і в результаті потрапляють в
master
. Git flow досить докладно і чітко визначає робочий процес, але його складність породжує дві проблеми.
По-перше, розробники повинні використовувати гілку
develop
, а не
master
, тому що остання зарезервована під релізний код. Це суперечить звичній практиці називати
master
основну гілку, від якої відгалужуються інші гілки, і в яку мержится результат. Нерідко розробники помилково мержат якісь зміни тільки в
master
, забуваючи про
develop
. А більшість графічних інтерфейсів до git за замовчуванням вважають основною гілкою саме
master
, тому в них доводиться кожен раз щось перемикати або налаштовувати.
По-друге, зайва складність з'являється з-за гілок релізів і хотфиксов. Більшість команд, особливо невеликих, може легко обійтися без них. Сьогодні більшість організацій дотримується практики безперервної доставки (continuous delivery), яка передбачає, що код з основної гілки можна розгортати на продакшен (production, той, що надається користувачам).
Отже, можна виключити гілки релізів і хотфиксов і всю зайву роботу, яка для них вимагається. Приклад такої зайвої роботи — зворотний мерж релізних гілок
master
. Для вирішення цієї проблеми є спеціальні інструменти, але вони теж потребують вивчення документації і тільки додають складності.
GitHub flow – більш простий варіант
Master branch with feature branches merged in
На противагу складної моделі git flow був розроблена модель GitHub flow. У ній є тільки
master
і feature-гілки. Це спрощення призвело до успішному впровадженню GitHub flow безліччю компаній. Компанія Atlassian запропонувала схожу стратегію. Але, на відміну від GitHub, вони воліють робити ребейз (rebase), а не мерж гілок
master
.
Мерж всіх змін в
master
і часте розгортання дозволяють не писати код «в стіл», а відразу випускати зміни. Це відповідає ідеям бережливого (lean) виробництва і безперервної доставки. Але багато питань залишаються без відповіді: коли саме потрібно розгортати і в яких середовищах, як випускати релізи, як пов'язати все це з трекером завдань. GitLab flow відповідає на всі ці питання.
GitLab flow: гілка production
Master branch and production branch with arrow indicate that deployments
GitHub flow будується на припущенні, що ви можете розгорнути ваш код на продакшен в будь-який момент, відразу після мержа feature-гілки в
master
. Це вірно для SaaS-додатків, але невірно в безлічі інших випадків. Буває, що ви не можете впливати на точний час релізу. Наприклад, ви випускаєте додаток під iOS і кожне оновлення має пройти валідацію в AppStore. Інший приклад — коли релізувати можна в строго певний час (наприклад, з 10 до 16 в будні дні, коли всі працівники знаходяться на робочому місці), але замержить гілку в
master
.
Для управління випуском коду в продакшен GitLab flow пропонує використовувати спеціальну гілку
production
. Налаштуйте автоматичне розгортання коду з цієї гілки при кожній зміні в ній. Тепер для релізу досить зробити мерж з гілки
master
на
production
. Стан гілки дасть вам точну інформацію про те, яка версія коду зараз випущена, а приблизний час випуску можна буде визначити по часу створення мерж-коміта. Якщо вам потрібна абсолютна точність, можна в процесі розгортання створювати новий тег з timestamp'ом в описі.
GitLab flow: гілки для кількох середовищ
Multiple branches with the code cascading from one to another
Може бути корисно мати окрему середовище (environment), в яку відбувається розгортання з гілки
master
.
В цьому єдиному випадку назва середовища може відрізнятися від назви гілки.
Припустимо, що у вас є кілька середовищ: стейджинг (staging), пре-продакшн (pre-production) і продакшен (production). Код
master
автоматично розгортається на стейджинг. Як тільки ви готові розгорнути його на пре-продакшн, ви створюєте мерж-реквест з
master
на
pre-production
. Відповідно, мерж з
pre-production
на
production
означає остаточний реліз. Такий процес, коли всі коміти проходять через гілки в строго визначеному порядку, гарантує, що зміни пройшли тестування у всіх середовищах.
Якщо вам потрібно швидко «протягнути» хотфикс на продакшн, то можна реалізувати його у звичайній feature-гілці, а потім відкрити мерж-реквест
master
, не видаляючи гілку. Тепер, якщо код
master
проходить тести і життєздатний (правильно налаштована безперервна доставка повинна гарантувати це), ви можете замержить гілку хотфикса послідовно
pre-production
та
production
. Якщо ж зміни вимагають додаткового тестування, то замість негайного мержа потрібно відкрити мерж-реквесты в ті ж гілки. В «екстремальному» випадку окрема середовище може створюватися для кожної гілки. Так робиться, наприклад, в Teatro.
GitLab flow: релизные гілки
Master and multiple release branches that vary in length with cherry-picks from master
Гілки релізів знадобляться вам тільки якщо ви випускаєте для зовнішніх клієнтів. У такому разі кожна мінорна версія буде зберігатися в окремій гілці (
2.3-stable
,
2.4-stable
тощо). Стабільні (stable) гілки повинні створюватися від гілки
master
. Їх потрібно створювати якомога пізніше, щоб мінімізувати додавання хотфиксов в кілька гілок. Після того, як релізна гілка створена, в неї можна включати тільки виправлення серйозних помилок. Слідуйте правилу "upstream first": завжди, коли це можливо, спочатку робіть мерж виправлень у
master
, і тільки звідти — cherry-pick у релізну гілку. Завдяки цьому правилу ви не забудете зробити cherry-pick виправлень у
master
та не зустрінете той самий баг в наступному релізі. Правило "upstream first" застосовується у тому числі в Google, Red Hat. Кожен раз, коли в релізну гілку додається виправлення бага, потрібно підвищити третє число у номері версії (за правилами семантичного версионирования). Позначте цю версію новим тегом в git. В деяких проектах використовується гілка
stable
, яка завжди вказує на той же комміт, що і останній реліз. Гілка
production
або
master
в правилах git flow) в такому випадку не потрібна.
GitLab flow: мерж/пулл-реквесты
Merge request line with comments
Мерж-реквест або пулл-реквест створюється в системі управління git-репозиторіями. Це запит на мерж однієї гілки на іншу, подібно задачі, який призначається на будь-якого виконавця. GitHub і Bitbucket використовують термін «пулл-реквевст», тому що перша необхідна дія — зробити пулл пропонованої гілки. GitLab і Gitorious використовують термін «мерж-реквест», тому що заключне дія — власне, мерж гілки. Далі в цій статті ми будемо називати це мерж-реквестом.
Якщо ви працюєте над гілкою більше, ніж пару годин, має сенс поділитися проміжним результатом з колегами через мерж-реквест. Не призначайте його на кого-небудь, а просто згадайте (командою
/cc @ім'я
) ваших колег в описі реквеста або в коментарі — вони отримають повідомлення. Це буде означати, що реквест не готовий до мержу, але по ньому вже можна давати зворотний зв'язок. Ви можете явно зазначити, що робота над реквестом не завершена. Для цього почніть заголовок реквеста з
[WIP]
або
WIP:
, "Work in progress". Такий мерж-реквест навіть не можна буде замержить через інтерфейс GitLab (хоча як і раніше можна вручну через git).
Інтерфейс GitLab дозволяє залишати коментарі до реквесту в цілому, так і до конкретних рядків коду. Таким чином, мерж-реквест вже включає в себе інструментарій для рев'ю коду, і якісь додаткові інструменти вам не знадобляться. За результатами рев'ю хто завгодно може внести правки наступним комітом в ту ж гілку (зазвичай це робить автор реквеста). Всі наступні коміти, запушенные в цю гілку, включаються в мерж-реквест, а діфф оновлюється автоматично і коректно працює навіть з
push -f
.
Коли фіча готова, і гілку можна мержить, призначте реквест на того, хто добре знає код проекту (і у кого є права на мерж
master
). Ця людина несе відповідальність за остаточне рев'ю і приймає рішення: замержить результат або закрити реквест без мержа.
У GitLab є стандартна практика — «захищати» довгоживучі гілки (такі як
master
або
production
). Захист гілки не дозволяє учасникам з рівнем доступу "Developer" пушити в неї будь-які зміни.
Тому для мержа в захищену гілку потрібно відкривати мерж-реквест, який призначається на учасника з більш високим рівнем доступу.
GitLab flow: інтеграція з завданнями (issues)
Merge with the request branch name 15-require-a-password to change it and assignee field shown
GitLab flow дозволяє вам явним чином пов'язувати код і завдання з трекера.
Будь-які суттєві зміни в коді повинні супроводжуватися завданням, в якій сформульовані вимоги і зміст змін. Це допомагає залишатися в рамках завдання, а також дає команді уявлення про те, чим ви зайняті. У GitLab кожна зміна кодової бази починається з оформлення завдання на трекері. Якщо передбачувані зміни хоч скільки-небудь серйозні (наприклад, вимагають більше години роботи), то роботу потрібно починати з оформлення завдання. Багато команд вже слідують цьому правилу, тому що завжди оцінюють час виконання завдання, перш ніж взяти її на спринт.
Заголовки завдань бажано формулювати так, щоб вони описували бажане стан системи.
Хороший приклад: «Як адміністратор, я хочу мати можливість видалити користувача без помилок».
Поганий приклад: «Адмін не може видаляти користувачів».
Приступаючи до роботи над завданням, створіть нову гілку від гілки
master
. Її назва повинна починатися з номера тікета, наприклад
42-admin-can-remove-users
.
Коли ви завершили роботу над завданням або хочете отримати проміжну зворотний зв'язок, відкривайте мерж-реквест. Пам'ятайте про можливості надіслати сповіщення (
/cc @ім'я
) колегам та позначці
WIP:
.
В момент, коли ви вважаєте, що робота завершена, призначте реквест на ревьюера і приберіть
WIP:
.
Ревьюер може прийняти (замержить) реквест як через командний рядок, так і через кнопку в інтерфейсі реквеста. Натискання на кнопку автоматично створює мерж-комміт, опис якого формується на основі опису реквеста. Мерж-отримати корисний тим, що він зберігає в історії час і обставини мержа. Тому, за замовчуванням, комміт створюється завжди, навіть якщо був можливий "fast forward merge", коли
master
просто переключається на останній комміт вашої гілки. В git ця стратегія називається "no fast forward" і використовується з командою
git merge --no-ff
. GitLab EE і .com пропонують вибір поведінки при мерже, подробиці далі у статті.
Feature-гілка зазвичай більше не потрібна після мержа, тому інтерфейс реквеста дозволяє видалити її. Припустимо, що гілка була замержена, після чого ви виявили якісь недоробки і перевідкрили завдання. Якщо стара гілка вилучена, можна створити нову гілку з тим же ім'ям і продовжити розробку в ній. Як правило, однієї задачі відповідає не більше однієї гілки, але в одній гілці може вирішуватися кілька завдань.
Зв'язування завдань і мерж-реквестов
Merge request showing the linked issues that will be closed
В повідомленні коміта, або в описі мерж-реквеста можна згадати завдання по її номеру, використовуючи слово-тригер, наприклад:
fixes #14
,
closes #67
. При цьому GitLab публікує у згаданій задачі коментар із зворотним посиланням на комміт або реквест. А в мерж-реквесте з'являється список пов'язаних завдань. Коли ви замержите код в основну гілку, пов'язані завдання будуть позначені як виконані. Зверніть увагу: тригери розпізнаються тільки англійською, тобто
fixes #14
спрацює, а
виправляє #14
— ні.
Якщо ви хочете створити посилання на задачу, але не закривати її, напишіть просто її номер: "Duck typing is preferred. #12".
Якщо деяка завдання охоплює кілька репозиторіїв, краще створити основну задачу в одному репозиторії і прив'язати до неї окремі завдання в інших репозиторіях.
Rebase і об'єднання комітів
Vim screen showing the rebase view
Git дозволяє об'єднати (squash) кілька комітів в один або змінити їхній порядок за допомогою команди
rebase -i
. У GitLab EE і .com ви можете зробити це безпосередньо перед мержем через веб-інтерфейс. Це має сенс, якщо в процесі роботи ви зробили кілька невеликих комітів, але хочете щоб у
master
потрапив один, або якщо хочете збудувати коміти в логічному порядку.
Пам'ятайте, що коміти, які вже потрапили у віддалений репозиторій і, тим більше, в стабільну гілку, ребейзить не можна. Причина цього в тому, що-небудь міг залишити посилання на них або витягнути (cherry-pick) у свою гілку. Ребейз змінює ідентифікатори (SHA-1) комітів, тому що фактично створює з них нові коміти. В результаті ваші зміни з'являються в історії git з кількома різними ідентифікаторами, що призводить до плутанини і помилок. Ребейз також ускладнює рев'ю коду, так як втрачається інформація про те, які зміни були внесені після рев'ю. Якщо об'єднуються коміти різних авторів, то інформація про авторство буде втрачена. Це позбавляє авторів вказівки на їх авторство, а ще заважає роботі
git blame
(показує, в якому коммите і ким змінювалася кожна рядок).
Регулярно робити коміти і пушити їх у віддалений репозиторій — хороша практика, що дозволяє колегам бачити, над чим ви працюєте. Але при такому підході одне завдання розмазується на багато комітів, так що історію розробки стає досить складно переглядати. Ці невеликі коміти можна було б об'єднати в один, але це призведе до втрати ідентифікаторів. Замість цього можна переглядати історію по мерж-коммитам: вони завжди пояснюють суть зміни і позначають момент мержа цілої гілки.
Зміни, які вже потрапили в
master
, не можна прати з історії і не так просто скасувати через
git revert
. Якщо все коміти були об'єднані в один за допомогою
rebase
, можна застосувати
revert
до цього єдиного коммиту. Проте ми переконані, що в об'єднанні комітів більше шкоди, ніж користі. На щастя, git вміє скасовувати мерж-коміти. Якщо ви передумали і хочете повернути скасований мерж-комміт, то застосовуйте
revert
до коммиту, створеному в результаті першого
revert
. Git все одно не дозволить вам замержить один і той ж отримати двічі.
Щоб це стало можливим, необхідно спочатку створити цей мерж-комміт. Тому, якщо ви мержите вручну, додайте опцію
--no-ff
. Система керування репозиторіями зробить це за вас в момент прийняття мерж-реквеста.
Не змінюйте порядок комітів з допомогою rebase
List of sequential merge commits
Git дозволяє вам зробити ребейз feature-гілки на
master
, в результаті чого коміти цієї гілки виявляються в історії після комітів
master
. Це дозволяє зробити мерж без мерж-коміта і в результаті у вас виходить проста лінійна історія. Але тут діє те ж правило, що і з об'єднанням комітів: не чіпайте то, що вже потрапило в віддалений репозиторій. Ми рекомендуємо не ребейзить навіть проміжні результати вашої роботи, віддані на рев'ю через мерж-реквест.
Використання
rebase
змушує вас багаторазово вирішувати одні й ті ж конфлікти. У деяких случах це можна зробити командою
git rerere
(reuse recorded resolutions). Але ще простіше — зовсім не ребейзить і вирішувати конфлікти всього один раз, при мерже. Ніж з меншою кількістю мерж-конфліктів ви стикаєтеся — тим краще.
Щоб уникнути зайвих конфліктів, потрібно не занадто часто мержить
master
в feature-гілки. Давайте розберемо три можливі причини мержа
master
куди-небудь ще: «підтягування коду» (leveraging code), мерж-конфлікти і довгоживучі гілки.
Якщо вам потрібно «підтягнути» зміни
master
в feature-гілку — зазвичай можна обійтися витягуванням (cherry-pick) одного потрібного коміта.
Конфлікт при мерже feature-гілки зазвичай вирішується за допомогою створення мерж-коміта. Якщо рядки вашого файлу можуть перебувати в довільному порядку, то можна уникнути деяких конфліктів за допомогою налаштування gitattributes. Наприклад, у файлі
.gitattributes
репозиторію GitLab є рядок
CHANGELOG merge=union
, і це дозволяє мержить список змін автоматично.
Остання ситуація, коли необхідно мержить
master
кудись ще — це використання довгоіснуючих гілок, які періодично потрібно оновлювати до актуального стану. Мартін Фаулер своїй статті про feature-гілках міркує про практику безперервної інтеграції (continuous integration, CI). Ми в GitLab трохи плутаємо CI з тестуванням гілок.
Цитуючи Фаулера: "Я знаю людей, які стверджують, що практикують CI, тому що виконують збірку кожної гілки і кожного коміта, і навіть можуть при цьому використовувати CI-сервер. Те, що вони роблять, називається безперервної складанням (continuous building). Це теж благородна справа, але інтеграції-то немає, а значить, немає і «безперервної інтеграції»."
Рішення полягає в тому, що feature-гілки повинні існувати недовго і швидко мержиться. Можна орієнтуватися на термін в один робочий день. Якщо розробник тримає гілку для реалізації завдання більше одного дня, подумайте про те, щоб роздрібнити завдання на більш дрібні частини. В якості альтернативи можна використовувати «перемикачі фіч» (feature toggles).
Для роботи з довгоживучими гілками є дві стратегії:
  • Стратегія безперервної інтеграції передбачає, що ви мержите
    master
    в довгоживучу гілку на початку кожного дня,
    щоб запобігти більш складні мержи в майбутньому.
  • Стратегія «точки синхронізації» (synchronization point strategy) дозволяє мержить тільки строго певні коміти,
    наприклад зазначені тегом релізи. Лінус Торвальдс рекомендує саме такий спосіб, тому що код релізних версій краще вивчений.
GitLab EE пропонує можливість робити rebase безпосередньо перед прийняттям мерж-реквеста. Ви можете включити цю можливість в налаштуваннях проекту, вибравши
Merge Requests Rebase
.
Merge request settings
Перед прийняттям мерж-реквеста виберіть опцію
rebase before merge
.
Merge request widget
GitLab спробує зробити rebase перед мержем. Якщо rebase без конфліктів неможливе, буде виконаний звичайний мерж.
На закінчення хотілося б сказати наступне: намагайтеся робити менше мерж-комітів, але не виключайте їх зовсім. Ваш код повинен бути чистим, але його історія повинна бути достовірною. Розробка ПЗ відбувається невеликими і не завжди красивими кроками. Те, що вони збережуться в історії коду — нормально. А ребейз робить історію недостовірної, після чого ніякі інструменти не покажуть вам дійсну історію, тому що вони не можуть дізнатися ідентифікатори комітів, які були до ребейза.
Використовуйте emoji в завданнях і мерж-реквестах
Emoji bar in GitLab
Загальноприйнята практика — висловлювати схвалення чи несхвалення з допомогою кнопок +1 і -1.
У GitLab ви можете використовувати emoji, щоб, наприклад, «дати п'ять» автору хорошою завдання або мерж-реквеста.
Пуш і видалення гілок
Remove checkbox for in branch merge requests
Ми рекомендуємо регулярно пушити локальні гілки у віддалений репозиторій, навіть якщо код ще не готовий до рев'ю. Таким чином ви страхуєтеся від ситуації, в якій хтось інший почав роботу над тим же завданням. Зрозуміло, більш правильний спосіб — призначити цій задачі виконавця з допомогою трекера завдань. Але іноді цей спосіб дає збій, просто тому що ніхто про це не згадав.
Коли гілка замержена
master
, її можна видалити з репозиторію. У GitLab і подібних йому системах це можна зробити безпосередньо під час мержа. Це гарантує, що при огляді гілок у системі керування репозиторіями, ви побачите тільки ті, над якими дійсно йде робота. А ще це звільняє ім'я і дозволяє назвати їм нову гілку. Це необхідно, якщо ви перевідкрили завдання і вам потрібна нова гілка і новий мерж-реквест.
Робіть коміти часто і пишіть до них коректні повідомлення
Good and bad commit message
Ми рекомендуємо почати коммитить код якомога раніше і робити це регулярно. Кожен раз, коли у вас є працюючий набір з коду і тестів до нього, можна зробити комміт. Перевага цього способу в тому, що якщо наступний етап роботи зайде в глухий кут, ви завжди зможете повернутися до робочої версії коду. Це кардинально відрізняється від роботи з SVN, де код можна коммитить тільки тоді, коли він повністю готовий. Коли ваша робота завершена, використовуйте мерж/пулл-реквест, щоб поділитися нею.
Повідомлення коміта має описувати ваші наміри, а не переказувати вміст коду — його і так нескладно подивитися. Важливо те, навіщо ви зробили це отримати.
Приклад хорошого повідомлення: «Скобминировать шаблони, щоб розвантажити інтерфейс користувача».
Деякі слова псують повідомлення, тому що нічого конкретного не значать: «змінити», «поліпшити», «отрефакторить» і т. п. Слова «лагодить», «виправляє» теж краще не використовувати, тільки якщо ви не пишете "fix" (тільки англійською) в кінці повідомлення і разом з номером завдання. Якщо ви хочете більше подробиць, рекомендуємо прочитати відмінну статтю з блогу Tim Pope.
Тестування перед мержем
Merge requests showing the test states, red, yellow and green
В старих моделях робочого процесу сервер безперервної інтеграції (CI server), як правило, запускав тести тільки на гілці
master
. Тому розробникам доводилося нести відповідальність за те, щоб не зламати
master
. У GitLab flow розробники створюють свої гілки від
master
, тому її завжди потрібно підтримувати «зеленої». Тому кожен мерж-реквест потрібно тестувати, перш ніж мержить. Інструменти CI, такі як GitLab CI або Travis, вміють показувати результати складання (build) безпосередньо в мерж-реквесте.
Слабке місце цього методу в тому, що тестується гілка, а не результат її мержа. Помилки можуть виникнути в процесі мержа, тому більш надійно тестувати результат. Складність цього підходу в тому, що цей результат змінюється кожен раз, коли у
master
потрапляють нові коміти. Повторення тестів кожен раз, коли змінюється
master
, вимагає великих обчислювальних ресурсів, так що ви набагато частіше будете чекати, поки пройдуть тести.
Якщо гілки мержатся швидко і конфліктів при мерже немає, то зазвичай можна ризикнути і замержить, не тестуючи результат. Якщо конфлікт усе-таки є, то можна замержить
master
в feature-гілку (тобто навпаки), після чого ваш сервер CI запустить тести на отриманому коммите. Якщо feature-гілки живуть довше, ніж кілька днів, варто подумати про зменшення масштабу ваших фіч.
Мерж чужого коду в код
Shell output showing git pull output
Коли починаєте роботу над завданням, завжди створюйте feature-гілку від останнього коміта
master
. Тільки якщо ваша робота вимагає змін з певної гілки, почніть з цієї гілки. Якщо згодом вам знадобилося замержить іншу гілку, обов'язково поясніть необхідність цього в повідомленні мерж-коміта. Поки ви не запушили вашу гілку в загальний репозиторій, можна ребейзить її на
master
або іншу гілку. Не потрібно мержить стабільні гілки в свої feature-гілки, якщо в цьому немає суворої необхідності. Лінус Торвальдс взагалі забороняє мержить стабільні гілки в feature-гілки, за винятком великих релізів.
Посилання
Переклад з англійської виконав nick_volynkin з невеликою допомогою перекладацької артілі «Надмозг і партнери», http://nadmosq.ru

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.