Branch
! Суть
bugfix/profile-avatar
Можливі проблеми:
Критично: main branch без protection швидко випадково зламати direct push-ем або неперевіреною зміною. Команди: Merge request — термін, який часто використовує GitLab.</syntaxhighlight>
Develop Branch
Ця команда покаже, які branches виступає як локально. PR описує що і навіщо змінено
!
<syntaxhighlight lang="text">
== Загальний SEO-опис ==
== Fast-Forward Merge ==
'''Практична роль:''' цей workflow створює branch від актуальної main, фіксує зміни й відправляє їх у remote repository.== конкурентні переваги Branch ==
До rebase:
'''Branch''' і '''fork''' теж різні. В open source branches використовують для:
'''критично:''' release branch має зменшувати ризик релізу, а не ставати місцем для хаотичного додавання нових features. git switch -c feature/profile-settings
== Deleting Branch ==
Приклади назв:
<div style="background:#e8f8f5; border-left:6px solid #16a085; padding:12px; margin:12px 0;">
* оновлювати docs разом із feature;
* готувати release notes;
* тримати docs для різних версій;
* review-ити documentation changes;
* генерувати preview docs;
* підтримувати long-term versions.
критично: якщо виступає як незбережені зміни, Git здатна не дозволити перемикання або зміни можуть переїхати в інший branch.== Merge ==
Основні конкурентні переваги branches:
</div>
\
</div>
зробити зміни
push branch
Merge request зазвичай містить:
'''Branch''' — це гілка розробки в системі контролю версій, яка дає можливість ізолювати зміни, працювати паралельно, робити code review, запускати CI й безпечніше інтегрувати новий код. * small pull requests;
* trunk-based development;
* feature flags;
* continuous integration;
* частими releases. Поняття
== Висновок ==
D--E
release/1.4.0
'''Проста ідея:''' fast-forward merge — це ніби main “наздогнав” branch без додаткового merge commit. feature/login-page
Branch рухається з новими commits.== Rebase ==
release/2026-05
'''критично:''' main branch не варто використовувати як місце для випадкових експериментів. * Feature flags допомагають зменшити потребу в довгоживучих branches. ↓
== Branch Protection ==
* Документація Git щодо branches, commits, merge, rebase і remote branches. * `git branch` показує local branches;
* `git branch -r` показує remote branches;
* `git branch -a` показує всі. '''Помилка:''' створити branch швидко. git checkout main
git switch -c feature/search
Long-lived branch — гілка, яка існує довго й накопичує багато змін. Перед switch краще зробити commit або stash. experiment/new-cache Bugfix branch — гілка для виправлення помилки. Практична роль: branch дає можливість contributor-у запропонувати зміни без прямого доступу до основного repository. bugfix/cart-total </syntaxhighlight> git status |- | Branch | Рухомий вказівник на лінію розробки | `feature/login` |- | Tag | Мітка на конкретному commit, часто для релізу | `v1.4.0` |}
Моделі:
Терміновий production bug
Приклад: критично: fork здатна містити власні branches. Практична роль: branch strategy — це правила дорожнього руху для коду. Приклади: Rebase створює нові commits з новими hashes. Перевага
Ризики Branch
Preview Environment
Local Branch і Remote Branch
- короткоживучі branches;
- часті merges;
- сильна CI;
- feature flags;
- small changes;
- швидкий feedback;
- main завжди має бути стабільним.</syntaxhighlight>
Stash корисний, якщо потрібно оперативно перемкнути branch, але зміни ще не готові для commit. Треба обережно налаштовувати доступ до secrets, особливо для зовнішніх contributors. A---B---C---D---E main Практична порада: використовуйте develop branch тільки якщо він справді потрібен вашому release process. Практична порада: якщо зміна не має потрапити в main прямо зараз, краще зробити branch. Якщо виник conflict:
<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
</div>
<syntaxhighlight lang="text">
'''Головне правило:''' branch має допомагати інтеграції, а не відкладати її назавжди. Конфлікт можна вирішити синтаксично правильно, але логічно неправильно.<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
Після merge:
</div>
Приклади:
</div>
<syntaxhighlight lang="text">
Merge здатна створити merge commit або пройти як fast-forward. git switch feature/profile-settings
</syntaxhighlight>
Branch hell — ситуація, коли branches стало занадто багато, вони живуть занадто довго, часто конфліктують і важко інтегруються.== Trunk-Based Development ==
Ідеї:
- створювати branch від актуального main;
- давати зрозумілі назви;
- робити branches короткоживучими;
- регулярно підтягувати зміни з main;
- робити маленькі pull requests;
- запускати CI;
- використовувати branch protection;
- не commit-ити secrets;
- видаляти merged branches;
- не тримати незавершену роботу місяцями;
- використовувати feature flags для довгих features;
- писати зрозумілий PR description;
- вирішувати conflicts уважно;
- мати командну branch strategy. Окремо варто відзначити а й для інших людей і CI/CD.== Приклад базового Git workflow ==
</syntaxhighlight> </syntaxhighlight>
Pull Request
↓
У main зазвичай зберігають:
Commit у Branch
title: "Account settings"
spike/payment-provider На remote:
Short-Lived Branch
Коли варто створювати Branch
Branch у Open Source
конкурентні переваги:
Класична схема містить:
Branch і CI/CD
Нова функція
Приклад:
* переглянути changes;
* провести code review;
* запустити CI;
* обговорити рішення для бізнесу;
* залишити comments;
* перевірити tests;
* побачити diff;
* контролювати merge. За змістом він дуже схожий на pull request. * Документація GitHub, GitLab і Bitbucket щодо pull requests, merge requests і branch protection.== Long-Lived Branch ==
<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
'''Небезпека:''' branch hell часто з’являється, коли команда відкладає інтеграцію “на потім”. fix/date-format
До secrets належать:
<syntaxhighlight lang="text">
== Branch і Stash ==
feature/user-settings
== Приклади сценаріїв використання ==
* подивитися UI;
* протестувати feature;
* показати зміни product manager;
* перевірити integration;
* знайти bugs до merge;
* отримати feedback. '''Небезпека:''' найпростіша помилка — внести зміни не в той branch. '''Merge conflict''' виникає, коли Git не здатна автоматизовано об’єднати зміни. '''критично:''' branch — інструмент.</div>
<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">
== Main Branch ==
* source branch;
* target branch;
* description;
* commits;
* diff;
* comments;
* approvals;
* CI results;
* merge options.<syntaxhighlight lang="bash">
</div>
== Merge Request ==
'''Практична роль:''' якщо в одному проєкті основна гілка називається `main`, а в іншому `master`, це не змінює саму ідею branch — змінюється лише назва. Інакше команда буде боротися не з багами, а з власним workflow. Створити нову гілку можна командою:
</div>
Git Flow добре підходив для проєктів із чіткими release cycles, але для continuous delivery іноді буває занадто важким.<syntaxhighlight lang="bash">
* contributions;
* pull requests;
* bug fixes;
* experiments;
* release maintenance;
* version support;
* documentation updates.
Підготовка релізу
Branch не відстав сильно від main
* хто здатна push у protected branches;
* чи потрібні reviews;
* чи проходять security scans;
* чи немає secrets у branch;
* чи не публікуються private changes;
* чи fork PR не має доступу до secrets;
* чи підписуються commits;
* чи обмежені deploy permissions;
* чи не можна обійти CI. * Branch protection — один із найпростіших способів захистити команду від випадкового зламу main.</div>
* У Git branch — це легкий pointer на commit, а не повна копія repository. Приклад створення:
* звідки робиться release;
* як робляться fixes;
* як backport-яться зміни;
* як ставляться tags;
* як функціонує rollback;
* хто має право merge;
* які CI checks required. відкрити pull request
Branch відповідає одній задачі
git commit -m "Add login form"
backport if needed
== Merge vs Rebase ==
<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
'''Найлюдяніший факт:''' branch — це як чернетка в зошиті: можна помилятися, виправляти, показати іншим і тільки потім переписати в чистовик. Приклад
git switch main
↓
</syntaxhighlight>
Branches використовують для:
Експеримент
hotfix/security-token
git stash pop
Найцікавіше, що branch у Git зазвичай дуже легкий. ! * Stale branches — це цифровий пил repository. A---B---C------M main
Або старіший варіант:
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
Ознаки:
Open pull request
Приклад:
Локально:
</div>
Такі branches можуть ніколи не потрапити в main. \
<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
== Branch Strategy ==
== Merge Conflict ==
test
- long-lived branches;
- merge conflicts;
- branch hell;
- stale branches;
- складні releases;
- дублювання роботи;
- CI не запускається;
- секрети в branch;
- неперевірені direct pushes;
- незрозумілі назви;
- багато незавершених PR;
- відставання від main;
- важке code review;
- залежність від однієї людини. Розробник створює `experiment/new-search-engine`, перевіряє підхід і після тестів або переносить ідею в normal branch, або видаляє експеримент.
=
title: "Account settings" >>>>>>> origin/main
Це означає, що одна й та сама частина файлу була змінена по-різному. git commit
Experimental Branch
Pull request дає можливість: Після fast-forward:
</syntaxhighlight> Проста різниця: branch — це дорога, tag — це пам’ятний знак на конкретному місці дороги. create hotfix branch Критично: якщо secret був у Git branch, вважайте його скомпрометованим, навіть якщо branch потім видалили. Для цього часто використовують окреме versioning або artifact storage. Приклад
До нормального version control розробники часто створювали копії папок із назвами на кшталт `project-final`, `project-final-2`, `project-real-final`, `project-final-fixed`. !Short-lived branches добре поєднуються з:
- ізолювати роботу;
- робити commits без ризику для main;
- запускати CI;
- пройти code review;
- обговорити зміни в pull request;
- об’єднати зміни тільки після готовності. * починається нова feature;
- потрібно виправити bug;
- потрібен hotfix;
- треба підготувати release;
- хочеться протестувати ідею;
- зміна потребує code review;
- робота займе більше одного commit;
- потрібно запустити CI окремо;
- зміна ризикована;
- ви працюєте в команді. критично: Git Flow не виступає як єдиним правильним workflow. * Pull request — це не тільки технічний merge, а й інструмент командної комунікації.</syntaxhighlight>
У develop можуть потрапляти:
- уникати довгоживучих branches;
- ховати незавершену feature;
- робити gradual rollout;
- тестувати в production;
- оперативно вимикати проблемну feature;
- підтримувати continuous delivery.
feature/user-profile
== Джерела ==
Приклади:
'''Fast-forward merge''' можливий, коли target branch не має нових commits після створення feature branch. Підхід
* видалити файл недостатньо;
* потрібно rotate secret;
* перевірити history;
* перевірити logs і CI;
* за потреби переписати history;
* повідомити команду безпеки. Після цього branch стане доступним команді й можна відкрити pull request або merge request. release/docs-1.5
main
== Hotfix Branch ==
Після rebase:
<syntaxhighlight lang="text">
Після цього зазвичай створюється pull request.</div>
↓
Branches можуть бути частиною release process. * складні merge conflicts;
* відставання від main;
* важке code review;
* прихована інтеграційна проблема;
* CI перевіряє застарілу основу;
* велика різниця з production;
* складніше rollback;
* ризик “branch hell”. ↓
<syntaxhighlight lang="bash">
Команда створює `hotfix/checkout-error`, виправляє payment issue, запускає CI й оперативно deploy-ить fix. A---B---C---F---G main
== Типові помилки початківців ==
Схематично:
</syntaxhighlight>
Тематичні мітки
Немає secrets
- edit files
Branch і tag — різні речі.== Branch Hell == Головна думка: branch — це безпечна робоча зона для змін. git push -u origin feature/profile-settings
refactor/order-service
- unit tests;
- integration tests;
- linting;
- type checks;
- security scans;
- build;
- preview deployment;
- code coverage;
- static analysis.
code review і CI checks Типовий бізнес-процес:
</syntaxhighlight>
Stale branches створюють шум і плутанину. Недолік
Git Flow — branching model із кількома типами branches. Він має допомагати команді швидше й чистіше інтегрувати код, а не створювати хаос із десятків забутих гілок. критично: branch strategy має відповідати release strategy.Практична роль: merge повертає роботу з branch назад у спільну лінію розробки. * release branch для кожної версії;
- tag-based releases;
- main завжди production-ready;
- long-term support branches;
- environment branches;
- hotfix branches. Branches можуть впливати на безпеку. Поняття
git rebase main
- `main` або `master`;
- `develop`;
- `feature/*`;
- `release/*`;
- `hotfix/*`. Підказка: branch має відповідати одній зрозумілій задачі. Commit фіксує зміни в поточному branch. Саме тому створити branch можна майже миттєво. * `main` і `master` можуть виконувати ту саму роль, але в різних проєктах називатися по-різному.== Приклад вирішення merge conflict ==
Приклад checklist для Branch
Приклад:
bugfix/payment-total experiment/react-compiler Commits мають зрозумілі повідомлення
release/mobile-2.1
Не можна commit-ити secrets у branch. git branch -d feature/login-page
</div>
Після commit branch вказує на новий commit.== Перемикання між Branches ==
Приклади назв:
<syntaxhighlight lang="bash">
Frontend-команди часто створюють preview deployment для кожного branch або pull request.== Branch і Release Management ==
* deploy preview для feature branch;
* deploy staging для release branch;
* deploy production після merge в main;
* запускати rollback workflows. Воно дає можливість:
== Stale Branch ==
=== Документація ===
'''Feature flags''' дозволяють merge-ити код у main, але вмикати функцію окремо. '''Stale branch''' — стара гілка, яка давно не оновлювалася. Git без зусиль пересуває pointer main вперед. release/2.0.0
! '''Практична роль:''' видалення merged branches підтримує repository чистим і зрозумілим. * Найкращі branches часто маленькі, зрозумілі й оперативно merge-яться. '''Проста думка:''' trunk-based development намагається уникати довгого життя змін у відриві від основного коду. Це різні рівні організації роботи.== Git Flow ==
== Branch у Data і ML-проєктах ==
\
↓
Рекомендовано:
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
* менше conflicts;
* швидший feedback;
* простіший review;
* ближче до main;
* легше підтримувати CI;
* менший ризик великого integration pain.<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
<div style="background:#e8f8f5; border-left:6px solid #16a085; padding:12px; margin:12px 0;">
git stash
<syntaxhighlight lang="bash">
'''Hotfix branch''' — гілка для термінового виправлення production-проблеми. * Матеріали щодо code review, release management, feature flags, DevOps, secure development і version control workflows.<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">
main: A---B---C
через '''Практична роль:''' bugfix branch користувачі можуть виправити конкретну проблему без змішування з іншими незавершеними changes.
{| class="wikitable"
\
* стабільний код;
* готові зміни;
* production-ready версію у частині workflow;
* код після code review;
* код після проходження tests;
* основу для нових branches.
↓
Merge conflicts вирішені уважно
↓
створити feature branch Release branch здатна використовуватися для:
У Git branch — це вказівник на commit.== Branch і Secrets ==
'''Критично:''' branch із pull request здатна запускати CI. local: feature/login-page
<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
git checkout main
* нових 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.<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
↓
Branch і Tags
* останній commit був давно;
* автор уже не функціонує над задачею;
* branch сильно відстав від main;
* PR неактивний;
* CI давно не запускався;
* задача втратила актуальність. Production bug found
Branches особливо корисні для features, bug fixes, hotfixes, releases, experiments і documentation changes. Це Git чесно каже: “Я не знаю, яку версію ти хочеш залишити”. Потрібно визначити:
git branch -r
Вони дозволяють:
'''Практична думка:''' merge краще показує, як гілки сходилися, а rebase робить історію чистішою для читання. '''Цікавий момент:''' branch здатна мати власну тимчасову “живу” версію застосунку, яку можна відкрити в браузері. bugfix/login-validation
Потрібно контролювати:
Commit changes
git branch
</div>
CI здатна запускати для branch:
До:
git add . Branch варто створювати, якщо:
'''Проста думка:''' pull request — це не без зусиль кнопка merge, а місце для перевірки, обговорення й якості.<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
Push branch to fork
* `feature/`;
* `bugfix/`;
* `hotfix/`;
* `release/`;
* `docs/`;
* `chore/`;
* `refactor/`;
* `test/`;
* `experiment/`. git branch feature/search
</div>
Після merge branch можна видалити
Rebase переносить commits branch на нову основу. feature/login-page → preview-login-page.example.com
== Master Branch ==
Тести проходять
У цьому прикладі `feature-login` відгалужився від `main` після commit `C`, а потім отримав власні commits `D` і `E`. Приклад:
|-
| Branch
| Гілка всередині repository
| `feature/search`
|-
| Fork
| Окрема копія repository в іншому namespace/account
| fork open source project на GitHub
|}
'''Практична порада:''' stash зручний для короткочасного зберігання, але не варто тримати важливу роботу тільки в stash надовго. Rebase переписує історію commits.<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
<syntaxhighlight lang="bash">
git pull origin main
Основна ідея: branch дає можливість працювати над змінами окремо від основної версії коду, щоб не заважати іншим і не ризикувати стабільністю проєкту.Практична роль: feature flag дає можливість відокремити merge коду від запуску функції для користувачів. git commit -m "Add profile settings page"
</syntaxhighlight>
Цікавий момент: хороший experimental branch здатна бути успішним навіть тоді, коли його видалили, бо команда дізналася, що підхід не функціонує.Ознаки:
</div>
↓
<<<<<<< HEAD
const title = "Home";
=======
const title = "Dashboard";
>>>>>>> feature/dashboard-title
Branch здатна бути зайвим, якщо:
== Bugfix Branch ==
== Branch і Fork ==
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
</div>
* experiment code;
* feature engineering;
* model training scripts;
* notebooks;
* pipeline changes;
* evaluation logic;
* documentation;
* model deployment code. CD здатна:
* main відстає від реальної роботи;
* develop стає нестабільним;
* release process ускладнюється;
* continuous deployment стає важчим.<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
↓
</div>
<syntaxhighlight lang="bash">
Branch protection здатна вимагати:
</div>
Назва branch зрозуміла
git pull origin main
<syntaxhighlight lang="text">
Release Branch
Практична роль: якщо код змінюється в branch, документація до нього теж здатна змінюватися в тому самому branch. * це дуже маленький solo project;
- зміна дрібна й безризикова;
- команда функціонує trunk-based із прямими small commits;
- виступає як сильна CI й pair programming;
- зміна лише локальна й не буде збережена;
- це тимчасова правка, яку краще зробити через stash.
Практична роль: pull request і merge request — різні назви для дуже схожої ідеї: контрольоване об’єднання змін. Branch protection — правила, які захищають важливі branches, як приклад `main`. Branches тісно пов’язані з CI/CD. feature/payment-history
Поширені префікси:
</syntaxhighlight>
Приклад:
Але великі datasets і model artifacts не завжди інтуїтивно зберігати прямо в Git branches.Схематично:
- ізоляція змін;
- паралельна робота;
- безпечні експерименти;
- code review;
- CI checks;
- легше release management;
- технічна підтримка hotfixes;
- чистіша історія продукту задач;
- контроль merge;
- краще командне workflow;
- можливість preview environments;
- технічна підтримка open source contributions;
- зменшення ризику для main.
це окрема лінія розвитку коду в системі контролю версій виступає ключовою рисою Branch або гілка. І це нормально: їхня цінність — навчання й перевірка ідеї. D---E feature
</syntaxhighlight>
Branch у CI Preview для Frontend
git pull origin main
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
У новіших версіях Git часто використовують:
! Branch застосовується для для ізоляції змін.<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
merge to main/release
'''Перевага:''' branch дає можливість команді працювати паралельно, але зберігати контроль над тим, що потрапляє в базовий код.
Merge — об’єднання змін із однієї гілки в іншу. Branches корисні не тільки для коду, а й для документації. docs/v2-migration-guide
Практична роль: CI/CD перетворює branch не без зусиль на місце для коду, а на перевірюваний кандидат для merge або release.* відкрити файл;
* вибрати правильний варіант або поєднати зміни;
* видалити conflict markers;
* протестувати код;
* зробити commit. '''Experimental branch''' — гілка для перевірки ідеї, proof of concept або ризикової зміни. * Практики software development щодо branching strategies, Git Flow, trunk-based development і CI/CD.</div>
'''Критично:''' hotfix має бути маленьким і сфокусованим.<syntaxhighlight lang="text">
Якщо secret потрапив у branch:
Типовий сценарій:
</div>
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
'''критично:''' чим довше branch живе окремо, тим дорожче його потім інтегрувати.</div>
Приклади:
remote: origin/feature/login-page
git switch main
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
</div>
Це оптимізує:
Типовий contributor workflow:
</syntaxhighlight> Branch strategy — правила команди щодо створення, використання й об’єднання branches. feature/search-filters
Це інтуїтивно для:
git add . У командній розробці це дає можливість кільком людям одночасно працювати над різними задачами.git checkout -b feature/login-page
* завершені features;
* bug fixes;
* зміни для наступної версії;
* інтеграційні зміни. !
У data science і machine learning branches використовують для:
Проста різниця: local branch живе у вас, remote branch — у спільному repository. Але в командній роботі branch або PR часто все одно корисний для review і history. Перед роботою завжди корисно зробити `git status`. Tag зазвичай лишається на одному commit.Або створити й одразу перейти на неї:
'''Практична роль:''' хороша назва branch одразу пояснює, навіщо він існує. У Git branch виступає як легким pointer на commit, тому branches оперативно створюються й активно використовуються в командній роботі.<syntaxhighlight lang="bash">
<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">
== Цікавий факт ==
* стабілізації;
* final testing;
* bug fixes перед релізом;
* version bump;
* release notes;
* deployment preparation;
* QA;
* backports. fix bug
</div>
== Branch і Security ==
Потім:
== Branch Naming Conventions ==
\ /
'''критично:''' merge conflict — це не катастрофа. Потім приходить одразу для всіх. У багатьох нових проєктах замість `master` використовують `main`. '''Головна перевага:''' branch дає можливість рухатися оперативно, але не змішувати незавершену роботу зі стабільним кодом.<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
Практична порада: краще робити кілька малих branches і PR, ніж один branch на 300 файлів. Проблеми long-lived branches:
| == Feature Branch ==
Short-lived branch — гілка, яка живе недовго й оперативно merge-иться.</syntaxhighlight> git branch -a Цікаві факти про BranchПриклади назв: Практична роль: commit — це збережений крок у межах branch.== Див. так само == Перед перемиканням варто перевірити статус: hotfix/payment-timeout Примусово локально: SEO title: Branch — гілка в Git, version control, розробці ПЗ, workflow і командній роботі SEO 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 </noinclude>
{{SEO
Шаблон для службового SEO-опису сторінки.
}}
git push -u origin feature/login-page Найлюдяніший факт: branch — це спосіб сказати: “Я хочу спробувати зміну, але не хочу одразу ламати все для команди”. Не варто разом із терміновим fix додавати “ще одну маленьку feature”. D---E feature Bugfix branch зазвичай короткоживучий: помилку виправили, тести пройшли, branch merged, branch видалили. develop branch часто застосовують, коли потрібно в Git Flow як інтеграційна гілка для майбутнього релізу.Stash тимчасово зберігає незакомічені зміни. Водночас вони потребують дисципліни: зрозумілі назви, короткий життєвий цикл, регулярна інтеграційні функції ERP, branch protection, CI checks і обережне вирішення conflicts. Hotfix branch часто створюють від стабільної production-гілки або tag. git branch
main branch — основна гілка repository. Його не треба створювати ритуально для кожного символу, але для більшості командних змін він дуже корисний. git switch main A---B---C main Remote branch існує в remote repository, як приклад на GitHub, GitLab або Bitbucket. Коли створюється новий commit у branch, branch починає вказувати на цей новий commit. Поширені помилки: Практична роль: створення branch — це перший крок перед ізольованою роботою над задачею. Create branch Local branch існує на комп’ютері розробника.</syntaxhighlight> </syntaxhighlight> Практична порада: періодично чистіть stale branches, але перед видаленням переконайтеся, що в них немає цінної роботи. Суть </syntaxhighlight> Fork часто використовують в open source, коли contributor не має direct write access до основного repository.== Push Branch == git branch -D feature/login-page git add . Це не повна копія всього проєкту, а вказівник на певний commit. Практична роль: checklist оптимізує зробити branch не без зусиль місцем для коду, а чистою частиною командного workflow. Вона має залишатися стабільною.== Branch і Feature Flags == deploy Feature branch дає можливість:
A---B---C main CI зелений Release branch — гілка для підготовки релізу. D---E feature feature-login: \---D Проста аналогія: branch — це закладка в історії коду, яка рухається вперед разом із новими commits. ↓ Хороші практики BranchСтворюється `release/2.3.0`, у якому роблять final fixes, оновлюють changelog і готують deployment. До merge: Проблема develop branch у деяких командах: Приклад: критично: після conflict обов’язково запускайте tests. Branch вирішує цю проблему цивілізовано: замість хаосу з копіями Git зберігає історію змін і дає можливість створювати багато ліній роботи в одному repository. Branch створено від актуального main
git switch feature/login-page merge назад у main Branch у DocumentationBranches мають ризики. Складніше — вчасно інтегрувати його назад або чесно видалити. Якщо в ньому вже три різні задачі, краще розділити роботу. Найчастіше цей термін використовують у '''Git''', де branch дає можливість розробнику працювати над новою функцією, виправленням помилки, експериментом або релізом, не ламаючи основну стабільну версію проєкту. Приклади:
Після merge branch часто видаляють.</div>
docs/api-authentication
<syntaxhighlight lang="bash">
↓
git checkout -b feature/search
<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
</div>
↓
== Створення Branch ==
</div>
<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
↓
hotfix/security-header | ||
|---|---|---|
| Merge | Зберігає реальну історію об’єднань | історія продукту здатна бути більш “гіллястою” |
| Rebase | Робить історію лінійнішою | Переписує commits і здатна заплутати команду при неправильному використанні |
Розробник створює `feature/password-reset`, додає форму відновлення пароля, пише тести, відкриває pull request і merge-ить у main після review. docs/api-auth
<syntaxhighlight lang="bash">
A---B---C main
'''Практична роль:''' preview environment дає можливість побачити branch як живий застосунок, а не тільки diff у коді. * яка гілка основна;
* коли створювати feature branch;
* як називати branches;
* хто здатна merge;
* чи потрібен PR;
* які CI checks required;
* як робити releases;
* як робити hotfixes;
* коли видаляти branches;
* як працювати з long-lived work;
* чи використовувати feature flags. D---E feature-login
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
Fork repository
Потрібно вручну обрати правильний варіант:
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
'''Trunk-based development''' — workflow, де розробники часто інтегрують зміни в основну гілку, яку часто називають trunk або main.== Коли Branch здатна бути зайвим ==
<div style="background:#e8f8f5; border-left:6px solid #16a085; padding:12px; margin:12px 0;">
== Branch у Git ==
'''Preview environment''' — тимчасове середовище, створене для branch або pull request. * Branch дає можливість експериментувати без ризику для main. Добрі назви branches допомагають команді розуміти контекст. ↓
Приклад:
</div>
Перемикання на іншу гілку:
</div>
Branch можна уявити як паралельну доріжку: базовий код рухається своїм шляхом, а розробник тимчасово відгалужується, робить зміни, тестує їх, а потім повертає назад через merge або pull request. '''Pull request''' або '''PR''' — запит на об’єднання змін із branch в іншу гілку, зазвичай у `main`. Для деяких команд краще trunk-based development або простіша модель. * Merge conflict — не помилка Git, а сигнал, що потрібне людське рішення для бізнесу. hotfix/broken-checkout
Щоб вирішити conflict:
Приклад:
</div>
- Git
- Version Control
- Source Control
- Commit
- Merge
- Rebase
- Pull Request
- Merge Request
- Merge Conflict
- Main Branch
- Feature Branch
- Hotfix Branch
- Release Branch
- Git Flow
- Trunk-Based Development
- CI/CD
- Code Review
- Branch Protection
- Tag
- Fork
- DevOps
- Software Development
- Документація
Branch strategy має визначати: