Перейти до вмісту

Branch

Матеріал з K2 ERP Wiki

Приклад:

Stale branches створюють шум і плутанину.;== Коли Branch має змогу бути зайвим == 

{{SEO
|title=Branch — гілка в Git, version control, розробці ПЗ, workflow і командній роботі
|description=Branch — Wiki-стаття про branch як гілку розробки у системах контролю версій, особливо Git. Розглянуто Git branch, main, master, feature branch, bugfix branch, release branch, hotfix branch, merge, rebase, pull request, merge conflict, trunk-based development, Git Flow, CI/CD, branch protection, naming conventions, переваги, ризики, цікаві факти і хороші практики.
|keywords=Branch, гілка, Git branch, version control, source control, Git, main branch, master branch, feature branch, bugfix branch, hotfix branch, release branch, merge, rebase, pull request, merge conflict, trunk-based development, Git Flow, branch protection, CI/CD, software development
|alternativeTo=розробка всіх змін прямо в main; копіювання папок project-final-v2; ручне збереження різних версій коду; робота без version control; хаотичні zip-архіви; long-lived code copies; зміни без pull request; deployment без відокремлення стабільного коду від експериментів
}}
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

git branch -r

experiment/new-cache

<<<<<<< HEAD
title: "Profile"
=======
title: "Account settings"
>>>>>>> origin/main

<syntaxhighlight lang="text">
Branch застосовується для ізоляції змін.;== Branch у Open Source ==
'''Практична порада:''' використовуйте develop branch тільки якщо він справді потрібен вашому release process.;<syntaxhighlight lang="bash">

</div>
Або створити й одразу перейти на неї:
<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

Обидві назви можуть означати основну гілку, але конкретна назва залежить від repository.; Open pull request
remote: origin/feature/login-page
</div>

bugfix/payment-total
  • unit tests;
  • integration tests;
  • linting;
  • type checks;
  • security scans;
  • build;
  • preview deployment;
  • code coverage;
  • static analysis.; Практична роль: preview environment надає можливість побачити branch як живий застосунок, а не тільки diff у коді.; До secrets належать:

Branch strategy має визначати: </syntaxhighlight>

Technical writer створює `docs/api-rate-limits`, оновлює документацію й відкриває PR для review.; ↓ 

Merge conflicts вирішені уважно

Примусово локально:

Short-lived branches добре поєднуються з:

* нових features;
* bug fixes;
* hotfixes;
* release preparation;
* experiments;
* refactoring;
* documentation changes;
* CI/CD testing;
* code review;
* temporary prototypes;
* migration work;
* long-running projects;
* open source contributions.; spike/payment-provider
== Release Branch ==
'''Проста різниця:''' branch — це дорога, tag — це пам’ятний знак на конкретному місці дороги.; bugfix/cart-total

title: "Account settings"
CI зелений
Feature branch надає можливість:

{| class="wikitable"

'''Головне правило:''' branch має допомагати інтеграції, а не відкладати її назавжди.; Приклади назв:

Bugfix Branch

До:

  • хто має змогу push у protected branches;
  • чи потрібні reviews;
  • чи проходять security scans;
  • чи немає secrets у branch;
  • чи не публікуються private changes;
  • чи fork PR не має доступу до secrets;
  • чи підписуються commits;
  • чи обмежені deploy permissions;
  • чи не можна обійти CI.; Вона має залишатися стабільною.;

Але великі datasets і model artifacts не завжди комфортно зберігати прямо в Git branches.; Branch protection має змогу вимагати:

На remote: У Git branch — це вказівник на commit.; * `git branch` показує local branches;

  • `git branch -r` показує remote branches;
  • `git branch -a` показує всі.; ↓

Підготовка релізу

 ↓

<syntaxhighlight lang="bash">
 D---E feature
 ↓

</div>

Ознаки:
feature/payment-history
git push -u origin feature/profile-settings

git commit
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
Приклад:

Git Flow добре підходив для проєктів із чіткими release cycles, але для continuous delivery іноді буває занадто важким.; git branch -D feature/login-page
'''Головна перевага:''' branch надає можливість рухатися оперативно, але не змішувати незавершену роботу зі стабільним кодом.; * Branch protection — один із найпростіших способів захистити команду від випадкового зламу main.; * Документація GitHub, GitLab і Bitbucket щодо pull requests, merge requests і branch protection.; Fork часто використовують в open source, коли contributor не має direct write access до основного repository.; '''Цікавий момент:''' хороший experimental branch має змогу бути успішним навіть тоді, коли його видалили, бо команда дізналася, що підхід не функціонує.;== Preview Environment ==
<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
git switch main

<div style="background:#e8f8f5; border-left:6px solid #16a085; padding:12px; margin:12px 0;">

'''Проста ідея:''' fast-forward merge — це ніби main “наздогнав” branch без додаткового merge commit.; '''Практична порада:''' stash зручний для короткочасного зберігання, але не варто тримати важливу роботу тільки в stash надовго.;<syntaxhighlight lang="text">
'''істотно:''' branch — інструмент.; !; відкрити pull request
git status
== Цікаві факти про Branch ==

</div>

Pull request надає можливість:
  • release branch для кожної версії;
  • tag-based releases;
  • main завжди production-ready;
  • long-term support branches;
  • environment branches;
  • hotfix branches.; Merge request — термін, який часто використовує GitLab.; * Branch надає можливість експериментувати без ризику для main.; * Найкращі branches часто маленькі, зрозумілі й оперативно merge-яться.; Команди:
  • десятки активних branches;
  • незрозуміло, що актуальне;
  • великі conflicts;
  • довгі code reviews;
  • features місяцями не merge-яться;
  • main сильно відрізняється від work branches;
  • release перетворюється на болісну інтеграцію.;

git merge feature/login-page

У main зазвичай зберігають: 

D---E feature

</syntaxhighlight>

переважні аспекти Branch

Розробник створює `experiment/new-search-engine`, перевіряє підхід і після тестів або переносить ідею в normal branch, або видаляє експеримент.; * Матеріали щодо code review, release management, feature flags, DevOps, secure development і version control workflows.; Суть develop branch часто застосовують, коли потрібно в Git Flow як інтеграційна гілка для майбутнього релізу.; Merge request зазвичай містить:

Hotfix branch часто створюють від стабільної production-гілки або tag.;

A---B---C---F---G---D'---E' feature 

== Main Branch ==
</div>

<syntaxhighlight lang="bash">

У цьому прикладі `feature-login` відгалужився від `main` після commit `C`, а потім отримав власні commits `D` і `E`.; Branches можуть впливати на безпеку.; release/2.0.0

Branch можна уявити як паралельну доріжку: ключовий код рухається своїм шляхом, а розробник тимчасово відгалужується, робить зміни, тестує їх, а потім повертає назад через merge або pull request.;</div>
git rebase main

</div>

A---B---C---F---G main
'''Rebase''' переносить commits branch на нову основу.; Локально:
=== Документація ===

</syntaxhighlight> 

'''Stash''' тимчасово зберігає незакомічені зміни.; * Pull request — це не тільки технічний merge, а й інструмент командної комунікації.; Команда створює `hotfix/checkout-error`, виправляє payment issue, запускає CI й оперативно deploy-ить fix.; create hotfix branch

</div>

== Push Branch ==

</syntaxhighlight> Merge має змогу створити merge commit або пройти як fast-forward.; ↓ 

== Branch і Release Management ==
<syntaxhighlight lang="text">

Branches можуть бути частиною release process.; * Практики software development щодо branching strategies, Git Flow, trunk-based development і CI/CD.; Це не повна копія всього проєкту, а вказівник на певний commit.; * останній commit був давно;

  • автор уже не функціонує над задачею;
  • branch сильно відстав від main;
  • PR неактивний;
  • CI давно не запускався;
  • задача втратила актуальність.;
  • звідки робиться release;
  • як робляться fixes;
  • як backport-яться зміни;
  • як ставляться tags;
  • як функціонує rollback;
  • хто має право merge;
  • які CI checks required.;
Якщо secret потрапив у branch:

</div>
Після merge branch часто видаляють.; Приклад

== Branch і Security ==

Можливі проблеми:
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
<syntaxhighlight lang="text">

Моделі:

Branch — це гілка розробки в системі контролю версій, яка надає можливість ізолювати зміни, працювати паралельно, робити code review, запускати CI й безпечніше інтегрувати новий код.; Приклади:

  • уникати довгоживучих branches;
  • ховати незавершену feature;
  • робити gradual rollout;
  • тестувати в production;
  • оперативно вимикати проблемну feature;
  • підтримувати continuous delivery.; істотно: якщо є собою незбережені зміни, Git має змогу не дозволити перемикання або зміни можуть переїхати в інший branch.;
    '''істотно:''' release branch має зменшувати ризик релізу, а не ставати місцем для хаотичного додавання нових features.; Commit фіксує зміни в поточному branch.; feature/login-page → preview-login-page.example.com
'''істотно:''' merge conflict — це не катастрофа.; Приклад
'''Практична роль:''' хороша назва branch одразу пояснює, навіщо він існує.; Типовий бізнес-процес:

|- | Branch | Рухомий вказівник на лінію розробки | `feature/login` |- | Tag | Мітка на конкретному commit, часто для релізу | `v1.4.0` |}

Небезпека: найпростіша помилка — внести зміни не в той branch.; git switch main

Висновок

Після цього branch стане доступним команді й можна відкрити pull request або merge request.; Не варто разом із терміновим fix додавати “ще одну маленьку feature”.;== Branch у CI Preview для Frontend ==

  • Документація Git щодо branches, commits, merge, rebase і remote branches.; У Git branch є собою легким pointer на commit, з цієї причини branches оперативно створюються й активно використовуються в командній роботі.; Branches мають ризики.;

Branch відповідає одній задачі git switch main

git stash

Приклад базового Git workflow

bugfix/login-validation

  • подивитися UI;
  • протестувати feature;
  • показати зміни product manager;
  • перевірити integration;
  • знайти bugs до merge;
  • отримати feedback.; Треба обережно налаштовувати доступ до secrets, особливо для зовнішніх contributors.;== Створення Branch ==

Trunk-based development — workflow, де розробники часто інтегрують зміни в основну гілку, яку часто називають trunk або main.; Rebase створює нові commits з новими hashes.; Поширені помилки:

</syntaxhighlight> git switch -c feature/search

</syntaxhighlight> Практична роль: merge повертає роботу з branch назад у спільну лінію розробки.; Fork repository

git pull origin main 

D---E feature
  • UI review;
  • дизайнерського feedback;
  • product review;
  • accessibility checks;
  • visual regression testing;
  • stakeholder demo;
  • QA до merge.; * Stale branches — це цифровий пил repository.;
* стабільний код;
* готові зміни;
* production-ready версію у частині workflow;
* код після code review;
* код після проходження tests;
* основу для нових branches.; * Long-lived branches часто створюють більше проблем, ніж здається на старті.; завдяки наявності '''Практична роль:''' bugfix branch користувачі можуть виправити конкретну проблему без змішування з іншими незавершеними changes.; зробити зміни
== Branch Hell ==
deploy

</div>

git stash pop

* починається нова feature;
* потрібно виправити bug;
* потрібен hotfix;
* треба підготувати release;
* хочеться протестувати ідею;
* зміна потребує code review;
* робота займе більше одного commit;
* потрібно запустити CI окремо;
* зміна ризикована;
* ви працюєте в команді.;<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
git branch -a

<syntaxhighlight lang="text">
<div style="background:#f0eaff; border-left:6px solid #8e44ad; padding:12px; margin:12px 0;">
'''Remote branch''' існує в remote repository, як ілюстрація на GitHub, GitLab або Bitbucket.; У багатьох нових проєктах замість `master` використовують `main`.; '''Проста думка:''' pull request — це не без ускладнень кнопка merge, а місце для перевірки, обговорення й якості.; CD має змогу:

docs/api-auth
</div>
</div>

== Local Branch і Remote Branch ==

Потрібно вручну обрати правильний варіант:

* створювати branch від актуального main;
* давати зрозумілі назви;
* робити branches короткоживучими;
* регулярно підтягувати зміни з main;
* робити маленькі pull requests;
* запускати CI;
* використовувати branch protection;
* не commit-ити secrets;
* видаляти merged branches;
* не тримати незавершену роботу місяцями;
* використовувати feature flags для довгих features;
* писати зрозумілий PR description;
* вирішувати conflicts уважно;
* мати командну branch strategy.;</div>

<div style="background:#f0eaff; border-left:6px solid #8e44ad; padding:12px; margin:12px 0;">

A---B---C main

* переглянути changes;
* провести code review;
* запустити CI;
* обговорити рішення для бізнесу;
* залишити comments;
* перевірити tests;
* побачити diff;
* контролювати merge.; Проблема develop branch у деяких командах:
!; A---B---C main

Після merge:
<syntaxhighlight lang="bash">
'''Практична роль:''' pull request і merge request — різні назви для дуже схожої ідеї: контрольоване об’єднання змін.; Якщо в ньому вже три різні задачі, краще розділити роботу.; git branch
<div style="background:#f0eaff; border-left:6px solid #8e44ad; padding:12px; margin:12px 0;">

створити feature branch

'''істотно:''' branch добре версіонує код, але не завжди підходить для великих binary artifacts або datasets.;<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
Branch рухається з новими commits.;</div>

'''Основна ідея:''' branch надає можливість працювати над змінами окремо від основної версії коду, щоб не заважати іншим і не ризикувати стабільністю проєкту.; docs/v2-migration-guide
Commit changes
== Branch і Feature Flags ==

</div>

'''Практична роль:''' feature branch — це робочий простір для конкретної задачі.; * Feature flags допомагають зменшити потребу в довгоживучих branches.; Tag зазвичай лишається на одному commit.; Перед роботою завжди корисно зробити `git status`.; Після merge branch можна видалити

== Тематичні мітки ==

== Feature Branch ==

 ↓
A---B---C------M main
merge to main/release
release/mobile-2.1
== Branch і Fork ==

Приклади:

* стабілізації;
* final testing;
* bug fixes перед релізом;
* version bump;
* release notes;
* deployment preparation;
* QA;
* backports.;<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

Щоб вирішити conflict:
== Див.; додатково ==
<div style="background:#e8f8f5; border-left:6px solid #16a085; padding:12px; margin:12px 0;">
Приклад:
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">
'''істотно:''' не робіть rebase shared branch без розуміння наслідків.; Потім приходить одразу для всіх.; * Merge conflict — не помилка Git, а сигнал, що потрібне людське рішення для бізнесу.; Недолік
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
<div style="background:#e8f8f5; border-left:6px solid #16a085; padding:12px; margin:12px 0;">
<syntaxhighlight lang="bash">
<syntaxhighlight lang="text">

Назва branch зрозуміла 

\

git add .; Інакше команда буде боротися не з багами, а з власним workflow.;== Merge ==

У новіших версіях Git часто використовують: 

\

Терміновий production bug

Приклади:

Це означає, що одна й та сама частина файлу була змінена по-різному.; main branch — основна гілка repository.; Після commit branch вказує на новий commit.;

Цікавий момент: branch має змогу мати власну тимчасову “живу” версію застосунку, яку можна відкрити в браузері.; Приклади:

</syntaxhighlight> 

↓

Поширені префікси:

Розробник створює `feature/password-reset`, додає форму відновлення пароля, пише тести, відкриває pull request і merge-ить у main після review.;== Branch Strategy ==

git checkout -b feature/search 

↓
  • короткоживучі branches;
  • часті merges;
  • сильна CI;
  • feature flags;
  • small changes;
  • швидкий feedback;
  • main завжди має бути стабільним.; test

В open source branches використовують для:

Експеримент

'''master''' — стара традиційна назва основної гілки Git repository.;</div>
== Branch і Tags ==
feature-login: \---D

<syntaxhighlight lang="bash">

* ізолювати роботу;
* робити commits без ризику для main;
* запускати CI;
* пройти code review;
* обговорити зміни в pull request;
* об’єднати зміни тільки після готовності.; !; Підхід
Перед перемиканням варто перевірити статус:
<syntaxhighlight lang="bash">

Щоб відправити branch у remote repository:

</div>
Класична схема охоплює:
'''Помилка:''' створити branch без зайвих зусиль.; У сучасних Git-проєктах її часто називають `main`.; Після цього зазвичай створюється pull request.; docs/api-authentication
 ↓
</div>

До merge:

</div>

 \ /

* `main` або `master`;
* `develop`;
* `feature/*`;
* `release/*`;
* `hotfix/*`.; !;</div>
Створюється `release/2.3.0`, у якому роблять final fixes, оновлюють changelog і готують deployment.; Саме з цієї причини створити branch можна майже миттєво.; Або старіший варіант:

Push branch to fork

  • завершені features;
  • bug fixes;
  • зміни для наступної версії;
  • інтеграційні зміни.; * deploy preview для feature branch;
  • deploy staging для release branch;
  • deploy production після merge в main;
  • запускати rollback workflows.; A---B---C---D---E main

Але в командній роботі branch або PR часто все одно корисний для review і history.; Branches використовують для:

Commit у Branch

  • це дуже маленький solo project;
  • зміна дрібна й безризикова;
  • команда функціонує trunk-based із прямими small commits;
  • є собою сильна CI й pair programming;
  • зміна лише локальна й не буде збережена;
  • це тимчасова правка, яку краще зробити через stash.;

істотно: fork має змогу містити власні branches.;

</syntaxhighlight> Branch має змогу бути зайвим, якщо:

</syntaxhighlight>

  • працювати прямо в main;
  • забути, в якому branch зараз знаходишся;
  • створити branch від застарілої main;
  • називати branch `test`, `new`, `fix`, `my-branch`;
  • не push-ити branch і втратити роботу;
  • тримати branch занадто довго;
  • боятися merge conflict;
  • робити величезний pull request;
  • rebase shared branch без розуміння;
  • видалити branch із незмердженою роботою;
  • commit-ити secrets;
  • не запускати tests перед merge;
  • не оновлювати branch перед review;
  • плутати branch і tag;
  • плутати branch і fork.; Водночас вони потребують дисципліни: зрозумілі назви, короткий життєвий цикл, регулярна інтеграційні функціональні можливості, branch protection, CI checks і обережне вирішення conflicts.; A---B---C main

Не можна commit-ити secrets у branch.; Перед switch краще зробити commit або stash.;== Branch Protection ==

  • long-lived branches;
  • merge conflicts;
  • branch hell;
  • stale branches;
  • складні releases;
  • дублювання роботи;
  • CI не запускається;
  • секрети в branch;
  • неперевірені direct pushes;
  • незрозумілі назви;
  • багато незавершених PR;
  • відставання від main;
  • важке code review;
  • залежність від однієї людини.;

Цікавий факт

Добрі назви branches допомагають команді розуміти контекст.; Це різні рівні організації роботи.; Проблеми long-lived branches:

git push origin --delete feature/login-page

prototype/new-dashboard

CI має змогу запускати для branch:

<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

PR описує що і навіщо змінено

<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

<syntaxhighlight lang="bash">

Branches особливо корисні для features, bug fixes, hotfixes, releases, experiments і documentation changes.; '''Практична роль:''' якщо в одному проєкті основна гілка називається `main`, а в іншому `master`, це не змінює саму ідею branch — змінюється лише назва.; '''Bugfix branch''' — гілка для виправлення помилки.; Потрібно визначити:

|- | Merge | Зберігає реальну історію об’єднань | історичний розвиток має змогу бути більш “гіллястою” |- | Rebase | Робить історію лінійнішою | Переписує commits і має змогу заплутати команду при неправильному використанні |}

Нова функція

feature/login-page

git branch -d feature/login-page

Short-Lived Branch

local: feature/login-page

Branch Naming Conventions

</syntaxhighlight>

Branch і fork теж різні.;

git pull origin main

Git без ускладнень пересуває pointer main вперед.; Для деяких команд краще trunk-based development або простіша модель.; Складніше — вчасно інтегрувати його назад або чесно видалити.;

Підказка: branch має відповідати одній зрозумілій задачі.;== Hotfix Branch ==

Ця команда покаже, які branches є собою локально.;
  • видалити файл недостатньо;
  • потрібно rotate secret;
  • перевірити history;
  • перевірити logs і CI;
  • за потреби переписати history;
  • повідомити команду безпеки.;</syntaxhighlight>

Це комфортно для:

Практична роль: commit — це збережений крок у межах branch.; * experiment code;

  • feature engineering;
  • model training scripts;
  • notebooks;
  • pipeline changes;
  • evaluation logic;
  • documentation;
  • model deployment code.;

Такі branches можуть ніколи не потрапити в main.; git checkout main

Feature branch — гілка для розробки нової функції.; backport if needed

Develop Branch

Вони дозволяють:

  • source branch;
  • target branch;
  • description;
  • commits;
  • diff;
  • comments;
  • approvals;
  • CI results;
  • merge options.;

Проста різниця: local branch живе у вас, remote branch — у спільному repository.; Branch не відстав сильно від main 

↓

hotfix/security-token <<<<<<< HEAD const title = "Home";

=

const title = "Dashboard"; >>>>>>> feature/dashboard-title

refactor/order-service

Приклад checklist для Branch

Проста аналогія: branch — це закладка в історії коду, яка рухається вперед разом із новими commits.; Release branch має змогу використовуватися для: Практична думка: merge краще показує, як гілки сходилися, а rebase робить історію чистішою для читання.; Branch вирішує цю проблему цивілізовано: замість хаосу з копіями Git зберігає історію змін і надає можливість створювати багато ліній роботи в одному repository.; У командній розробці це надає можливість кільком людям одночасно працювати над різними задачами.; git commit -m "Add login form" </syntaxhighlight> переважні аспекти:

Приклад вирішення merge conflict

  • У Git branch — це легкий pointer на commit, а не повна копія repository.;

Практична роль: branch надає можливість contributor-у запропонувати зміни без прямого доступу до основного repository.; git switch main

  • відкрити файл;
  • вибрати правильний варіант або поєднати зміни;
  • видалити conflict markers;
  • протестувати код;
  • зробити commit.; У data science і machine learning branches використовують для:

experiment/react-compiler

release/2026-05

  1. edit files

Приклад: Приклад:

Найлюдяніший факт: branch — це як чернетка в зошиті: можна помилятися, виправляти, показати іншим і тільки потім переписати в чистовик.; І це нормально: їхня цінність — навчання й перевірка ідеї.; Тести проходять

  • main відстає від реальної роботи;
  • develop стає нестабільним;
  • release process ускладнюється;
  • continuous deployment стає важчим.; {| class="wikitable"

fix/date-format

Branch і Secrets

== Ризики Branch ==

feature/user-profile

* менше conflicts;
* швидший feedback;
* простіший review;
* ближче до main;
* легше підтримувати CI;
* менший ризик великого integration pain.;<syntaxhighlight lang="bash">

</syntaxhighlight>

  • API keys;
  • passwords;
  • private keys;
  • tokens;
  • cloud credentials;
  • database URLs із паролем;
  • signing keys;
  • OAuth secrets.;== Коли варто створювати Branch ==
Stash корисний, якщо потрібно оперативно перемкнути branch, але зміни ще не готові для commit.;

git commit -m "Add profile settings page"

</syntaxhighlight> Схематично:

Experimental Branch

Приклади:
'''Перевага:''' branch надає можливість команді працювати паралельно, але зберігати контроль над тим, що потрапляє в ключовий код.; Приклад створення:
!; Це сприяє:
<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
<syntaxhighlight lang="bash">

* ізоляція змін;
* паралельна робота;
* безпечні експерименти;
* code review;
* CI checks;
* легше release management;
* супровід hotfixes;
* чистіша історичний розвиток задач;
* контроль merge;
* краще командне workflow;
* можливість preview environments;
* супровід open source contributions;
* зменшення ризику для main.; push branch

</div>

перевірки ідеї забезпечується через Experimental branch — гілка; додатково реалізовано proof of concept або ризикової зміни.; Практична порада: періодично чистіть stale branches, але перед видаленням переконайтеся, що в них немає цінної роботи.; Проста думка: trunk-based development намагається уникати довгого життя змін у відриві від основного коду.; Практична роль: checklist сприяє зробити branch не без ускладнень місцем для коду, а чистою частиною командного workflow.; Приклад: 

↓

Практична роль: якщо код змінюється в branch, документація до нього теж має змогу змінюватися в з цієї причини самому branch.; * `main` і `master` можуть виконувати ту саму роль, але в різних проєктах називатися по-різному.; Preview environment — тимчасове середовище, створене для branch або pull request.; Hotfix branch — гілка для термінового виправлення production-проблеми.; це окрема лінія розвитку коду в системі контролю версій виступає ключовою рисою Branch або гілка.; До rebase:

Branch у Git

\

git add .; git switch feature/login-page

Merge Conflict

Branch і Stash

release/docs-1.5 

'''Release branch''' — гілка для підготовки релізу.; Створити нову гілку можна командою:
== Branch у Data і ML-проєктах ==

'''Практична порада:''' краще робити кілька малих branches і PR, ніж один branch на 300 файлів.; Його не треба створювати ритуально для кожного символу, але для більшості командних змін він дуже корисний.; ↓
'''Merge conflict''' виникає, коли Git не має змогу автономно об’єднати зміни.; * pull request перед merge;
* code review;
* passing CI checks;
* no direct push;
* signed commits;
* up-to-date branch;
* required approvals;
* status checks;
* restricted users;
* linear history;
* security scans.; Поняття

Fast-Forward Merge

bugfix/profile-avatar

Перемикання між Branches

Після fast-forward:

hotfix/broken-checkout Short-lived branch — гілка, яка живе недовго й оперативно merge-иться.; Конфлікт можна вирішити синтаксично правильно, але логічно неправильно.; Branch hell — ситуація, коли branches стало занадто багато, вони живуть занадто довго, часто конфліктують і важко інтегруються.;</syntaxhighlight>

  • small pull requests;
  • trunk-based development;
  • feature flags;
  • continuous integration;
  • частими releases.;</syntaxhighlight>

Stale Branch

git checkout main

Приклад:

Branches корисні не тільки для коду, а й для документації.; Потрібно контролювати:

істотно: main branch не варто використовувати як місце для випадкових експериментів.; feature/search-filters

Основні переважні аспекти branches:

!; git branch feature/search Практична порада: якщо зміна не має потрапити в main прямо зараз, краще зробити branch.; Перевага git switch -c feature/profile-settings

</syntaxhighlight>

</syntaxhighlight>

Приклади назв:

істотно: branch strategy має відповідати release strategy.;
'''Branch protection''' — правила, які захищають важливі branches, як ілюстрація `main`.; До нормального version control розробники часто створювали копії папок із назвами на кшталт `project-final`, `project-final-2`, `project-real-final`, `project-final-fixed`.; Production bug found

<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

Схематично:

'''Критично:''' hotfix має бути маленьким і сфокусованим.; code review і CI checks
'''Головна думка:''' branch — це безпечна робоча зона для змін.; Найчастіше цей термін використовують у '''Git''', де branch надає можливість розробнику працювати над новою функцією, виправленням помилки, експериментом або релізом, не ламаючи основну стабільну версію проєкту.; git branch
</div>
== Хороші практики Branch ==

== Merge Request ==

Branch варто створювати, якщо:

git push -u origin feature/login-page 

Ідеї:
|-
| Branch
| Гілка всередині repository
| `feature/search`
|-
| Fork
| Окрема копія repository в іншому namespace/account
| fork open source project на GitHub
|}

<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">

</div>
</div>
'''Практична роль:''' видалення merged branches підтримує роботу repository чистим і зрозумілим.; Rebase переписує історію commits.; '''Небезпека:''' branch hell часто з’являється, коли команда відкладає інтеграцію “на потім”.; Воно надає можливість:

</syntaxhighlight>

Типовий contributor workflow: Найлюдяніший факт: branch — це спосіб сказати: “Я хочу спробувати зміну, але не хочу одразу ламати все для команди”.; За змістом він дуже схожий на pull request.; Для цього часто використовують окреме versioning або artifact storage.; Критично: branch із pull request має змогу запускати CI.; * оновлювати docs разом із feature;

  • готувати release notes;
  • тримати docs для різних версій;
  • review-ити documentation changes;
  • генерувати preview docs;
  • підтримувати long-term versions.; * складні merge conflicts;
  • відставання від main;
  • важке code review;
  • прихована інтеграційна проблема;
  • CI перевіряє застарілу основу;
  • велика різниця з production;
  • складніше rollback;
  • ризик “branch hell”.;

Merge vs Rebase

Branch і CI/CD

Практична роль: branch strategy — це правила дорожнього руху для коду.; Stale branch — стара гілка, яка давно не оновлювалася.;
Create branch
!; Поняття

merge назад у main

</div>
'''Практична роль:''' створення branch — це перший крок перед ізольованою роботою над задачею.; '''Branch strategy''' — правила команди щодо створення, використання й об’єднання branches.; Ознаки:
release/1.4.0

'''Fast-forward merge''' можливий, коли target branch не має нових commits після створення feature branch.;<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
'''Pull request''' або '''PR''' — запит на об’єднання змін із branch в іншу гілку, зазвичай у `main`.;<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

Приклад:

</div>

Commits мають зрозумілі повідомлення

* `feature/`;
* `bugfix/`;
* `hotfix/`;
* `release/`;
* `docs/`;
* `chore/`;
* `refactor/`;
* `test/`;
* `experiment/`.; git checkout -b feature/login-page
'''Критично:''' main branch без protection без зайвих зусиль випадково зламати direct push-ем або неперевіреною зміною.; '''істотно:''' чим довше branch живе окремо, тим дорожче його потім інтегрувати.;== Master Branch ==
Немає secrets
'''Критично:''' якщо secret був у Git branch, вважайте його скомпрометованим, навіть якщо branch потім видалили.; git add .; '''Long-lived branch''' — гілка, яка існує довго й накопичує багато змін.; Приклад:

hotfix/payment-timeout

Merge — об’єднання змін із однієї гілки в іншу.;
'''Local branch''' існує на комп’ютері розробника.;</div>
fix bug
Якщо виник conflict:
'''Feature flags''' дозволяють merge-ити код у main, але вмикати функцію окремо.;== Git Flow ==

 D---E feature-login
Перемикання на іншу гілку:
'''Git Flow''' — branching model із кількома типами branches.; Коли створюється новий commit у branch, branch починає вказувати на цей новий commit.; Frontend-команди часто створюють preview deployment для кожного branch або pull request.; Це Git чесно каже: “Я не знаю, яку версію ти хочеш залишити”.; Найцікавіше, що branch у Git зазвичай дуже легкий.; feature/user-settings

== Типові помилки початківців ==

* contributions;
* pull requests;
* bug fixes;
* experiments;
* release maintenance;
* version support;
* documentation updates.; '''Branch''' і '''tag''' — різні речі.; '''Практична роль:''' push робить вашу гілку видимою не тільки локально.;== Приклади сценаріїв використання ==

== Deleting Branch ==

Branch створено від актуального main

</div>
== Джерела ==
</div>

== Branch у Documentation ==

<syntaxhighlight lang="text">
<syntaxhighlight lang="text">
<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

<syntaxhighlight lang="text">

 \
 ↓
{| class="wikitable"

Рекомендовано:
<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">
Типовий сценарій:

hotfix/security-header

main: A---B---C

'''істотно:''' Git Flow не є собою єдиним правильним workflow.; Bugfix branch зазвичай короткоживучий: помилку виправили, тести пройшли, branch merged, branch видалили.; Після rebase:

!;

Trunk-Based Development

</syntaxhighlight>

  • яка гілка основна;
  • коли створювати feature branch;
  • як називати branches;
  • хто має змогу merge;
  • чи потрібен PR;
  • які CI checks required;
  • як робити releases;
  • як робити hotfixes;
  • коли видаляти branches;
  • як працювати з long-lived work;
  • чи використовувати feature flags.;== Long-Lived Branch ==

git pull origin main

Практична роль: цей workflow створює branch від актуальної main, фіксує зміни й відправляє їх у remote repository.; Суть

main 

↓
Branches тісно пов’язані з CI/CD.;
 ↓

Потім:

</div>

 ↓
'''істотно:''' після conflict обов’язково запускайте tests.; Окремо варто відзначити а й для інших людей і CI/CD.; git switch feature/profile-settings
== Pull Request ==
'''Практична роль:''' feature flag надає можливість відокремити merge коду від запуску функції для користувачів.; D--E
!; Він має допомагати команді швидше й чистіше інтегрувати код, а не створювати хаос із десятків забутих гілок.;== Загальний характеристика ==

Rebase

<syntaxhighlight lang="bash">

Практична роль: CI/CD перетворює branch не без ускладнень на місце для коду, а на перевірюваний кандидат для merge або release.;

Приклади назв:

У develop можуть потрапляти:

Отримано з https://wiki.corp2.eu/index.php?title=Branch&oldid=1393