Branch

Branch або гілка — це окрема лінія розвитку коду в системі контролю версій. Найчастіше цей термін використовують у Git, де branch дозволяє розробнику працювати над новою функцією, виправленням помилки, експериментом або релізом, не ламаючи основну стабільну версію проєкту.

Branch можна уявити як паралельну доріжку: основний код рухається своїм шляхом, а розробник тимчасово відгалужується, робить зміни, тестує їх, а потім повертає назад через merge або pull request.

Основна ідея: branch дозволяє працювати над змінами окремо від основної версії коду, щоб не заважати іншим і не ризикувати стабільністю проєкту.

Цікавий факт

До нормального version control розробники часто створювали копії папок із назвами на кшталт `project-final`, `project-final-2`, `project-real-final`, `project-final-fixed`. Branch вирішує цю проблему цивілізовано: замість хаосу з копіями Git зберігає історію змін і дозволяє створювати багато ліній роботи в одному repository.

Найцікавіше, що branch у Git зазвичай дуже легкий. Це не повна копія всього проєкту, а вказівник на певний commit. Саме тому створити branch можна майже миттєво.

Найлюдяніший факт: branch — це спосіб сказати: “Я хочу спробувати зміну, але не хочу одразу ламати все для команди”.

Загальний опис

Branch використовується для ізоляції змін. У командній розробці це дозволяє кільком людям одночасно працювати над різними задачами.

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.

Типовий процес:

main
  ↓
створити feature branch
  ↓
зробити зміни
  ↓
push branch
  ↓
відкрити pull request
  ↓
code review і CI checks
  ↓
merge назад у main

Перевага: branch дозволяє команді працювати паралельно, але зберігати контроль над тим, що потрапляє в основний код.

Branch у Git

У Git branch — це вказівник на commit. Коли створюється новий commit у branch, branch починає вказувати на цей новий commit.

Приклад:

A---B---C  main
         \
          D---E  feature-login

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

Проста аналогія: branch — це закладка в історії коду, яка рухається вперед разом із новими commits.

Main Branch

main branch — основна гілка repository. У сучасних Git-проєктах її часто називають `main`.

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

стабільний код;
готові зміни;
production-ready версію у частині workflow;
код після code review;
код після проходження tests;
основу для нових branches.

Приклад:

git checkout main
git pull origin main

Важливо: main branch не варто використовувати як місце для випадкових експериментів. Вона має залишатися стабільною.

Master Branch

master — стара традиційна назва основної гілки Git repository. У багатьох нових проєктах замість `master` використовують `main`.

Обидві назви можуть означати основну гілку, але конкретна назва залежить від repository.

git branch

Ця команда покаже, які branches є локально.

Практична роль: якщо в одному проєкті основна гілка називається `main`, а в іншому `master`, це не змінює саму ідею branch — змінюється лише назва.

Feature Branch

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

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

feature/login-page
feature/payment-history
feature/user-profile
feature/search-filters

Feature branch дозволяє:

ізолювати роботу;
робити commits без ризику для main;
запускати CI;
пройти code review;
обговорити зміни в pull request;
об’єднати зміни тільки після готовності.

Приклад створення:

git checkout -b feature/login-page

Практична роль: feature branch — це робочий простір для конкретної задачі.

Bugfix Branch

Bugfix branch — гілка для виправлення помилки.

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

bugfix/login-validation
bugfix/cart-total
bugfix/profile-avatar
fix/date-format

Bugfix branch зазвичай короткоживучий: помилку виправили, тести пройшли, branch merged, branch видалили.

Практична роль: bugfix branch допомагає виправити конкретну проблему без змішування з іншими незавершеними changes.

Hotfix Branch

Hotfix branch — гілка для термінового виправлення production-проблеми.

Приклади:

hotfix/payment-timeout
hotfix/security-header
hotfix/broken-checkout

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

Типовий сценарій:

Production bug found
  ↓
create hotfix branch
  ↓
fix bug
  ↓
test
  ↓
merge to main/release
  ↓
deploy
  ↓
backport if needed

Критично: hotfix має бути маленьким і сфокусованим. Не варто разом із терміновим fix додавати “ще одну маленьку feature”.

Release Branch

Release branch — гілка для підготовки релізу.

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

release/1.4.0
release/2026-05
release/mobile-2.1

Release branch може використовуватися для:

стабілізації;
final testing;
bug fixes перед релізом;
version bump;
release notes;
deployment preparation;
QA;
backports.

Важливо: release branch має зменшувати ризик релізу, а не ставати місцем для хаотичного додавання нових features.

Experimental Branch

Experimental branch — гілка для перевірки ідеї, proof of concept або ризикової зміни.

Приклади:

experiment/new-cache
experiment/react-compiler
spike/payment-provider
prototype/new-dashboard

Такі branches можуть ніколи не потрапити в main. І це нормально: їхня цінність — навчання й перевірка ідеї.

Цікавий момент: хороший experimental branch може бути успішним навіть тоді, коли його видалили, бо команда дізналася, що підхід не працює.

Local Branch і Remote Branch

Local branch існує на комп’ютері розробника. Remote branch існує в remote repository, наприклад на GitHub, GitLab або Bitbucket.

Приклади:

local:  feature/login-page
remote: origin/feature/login-page

Команди:

git branch
git branch -r
git branch -a

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

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

Створення Branch

Створити нову гілку можна командою:

git branch feature/search

Або створити й одразу перейти на неї:

git checkout -b feature/search

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

git switch -c feature/search

Практична роль: створення branch — це перший крок перед ізольованою роботою над задачею.

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

Перемикання на іншу гілку:

git switch main

Або старіший варіант:

git checkout main

Перед перемиканням варто перевірити статус:

git status

Важливо: якщо є незбережені зміни, Git може не дозволити перемикання або зміни можуть переїхати в інший branch. Перед switch краще зробити commit або stash.

Commit у Branch

Commit фіксує зміни в поточному branch.

Приклад:

git add .
git commit -m "Add login form"

Після commit branch вказує на новий commit.

main:          A---B---C
feature-login:         \---D

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

Push Branch

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

git push -u origin feature/login-page

Після цього branch стане доступним команді й можна відкрити pull request або merge request.

Практична роль: push робить вашу гілку видимою не тільки локально, а й для інших людей та CI/CD.

Pull Request

Pull request або PR — запит на об’єднання змін із branch в іншу гілку, зазвичай у `main`.

Pull request дозволяє:

переглянути changes;
провести code review;
запустити CI;
обговорити рішення;
залишити comments;
перевірити tests;
побачити diff;
контролювати merge.

Проста думка: pull request — це не просто кнопка merge, а місце для перевірки, обговорення й якості.

Merge Request

Merge request — термін, який часто використовує GitLab. За змістом він дуже схожий на pull request.

Merge request зазвичай містить:

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

Практична роль: pull request і merge request — різні назви для дуже схожої ідеї: контрольоване об’єднання змін.

Merge

Merge — об’єднання змін із однієї гілки в іншу.

Приклад:

git switch main
git merge feature/login-page

Merge може створити merge commit або пройти як fast-forward.

Схематично:

До merge:

A---B---C  main
         \
          D---E  feature

Після merge:

A---B---C------M  main
         \    /
          D--E

Практична роль: merge повертає роботу з branch назад у спільну лінію розробки.

Fast-Forward Merge

Fast-forward merge можливий, коли target branch не має нових commits після створення feature branch.

Приклад:

До:

A---B---C  main
         \
          D---E  feature

Після fast-forward:

A---B---C---D---E  main

Git просто пересуває pointer main вперед.

Проста ідея: fast-forward merge — це ніби main “наздогнав” branch без додаткового merge commit.

Rebase

Rebase переносить commits branch на нову основу.

Приклад:

git switch feature/login-page
git rebase main

Схематично:

До rebase:

A---B---C---F---G  main
         \
          D---E    feature

Після rebase:

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

Rebase створює нові commits з новими hashes.

Важливо: не робіть rebase shared branch без розуміння наслідків. Rebase переписує історію commits.

Merge vs Rebase

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

Практична думка: merge краще показує, як гілки сходилися, а rebase робить історію чистішою для читання.

Merge Conflict

Merge conflict виникає, коли Git не може автоматично об’єднати зміни.

Приклад:

<<<<<<< HEAD
const title = "Home";
=======
const title = "Dashboard";
>>>>>>> feature/dashboard-title

Це означає, що одна й та сама частина файлу була змінена по-різному.

Щоб вирішити conflict:

відкрити файл;
вибрати правильний варіант або поєднати зміни;
видалити conflict markers;
протестувати код;
зробити commit.

Важливо: merge conflict — це не катастрофа. Це Git чесно каже: “Я не знаю, яку версію ти хочеш залишити”.

Branch Protection

Branch protection — правила, які захищають важливі branches, наприклад `main`.

Branch protection може вимагати:

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.

Критично: main branch без protection легко випадково зламати direct push-ем або неперевіреною зміною.

Branch Naming Conventions

Добрі назви branches допомагають команді розуміти контекст.

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

`feature/`;
`bugfix/`;
`hotfix/`;
`release/`;
`docs/`;
`chore/`;
`refactor/`;
`test/`;
`experiment/`.

Приклади:

feature/user-settings
bugfix/payment-total
hotfix/security-token
docs/api-authentication
refactor/order-service
release/2.0.0

Практична роль: хороша назва branch одразу пояснює, навіщо він існує.

Long-Lived Branch

Long-lived branch — гілка, яка існує довго й накопичує багато змін.

Проблеми long-lived branches:

складні merge conflicts;
відставання від main;
важке code review;
прихована інтеграційна проблема;
CI перевіряє застарілу основу;
велика різниця з production;
складніше rollback;
ризик “branch hell”.

Важливо: чим довше branch живе окремо, тим дорожче його потім інтегрувати.

Short-Lived Branch

Short-lived branch — гілка, яка живе недовго й швидко merge-иться.

Переваги:

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

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

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

Практична порада: краще робити кілька малих branches і PR, ніж один branch на 300 файлів.

Trunk-Based Development

Trunk-based development — workflow, де розробники часто інтегрують зміни в основну гілку, яку часто називають trunk або main.

Ідеї:

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

Проста думка: trunk-based development намагається уникати довгого життя змін у відриві від основного коду.

Git Flow

Git Flow — branching model із кількома типами branches.

Класична схема включає:

`main` або `master`;
`develop`;
`feature/*`;
`release/*`;
`hotfix/*`.

Git Flow добре підходив для проєктів із чіткими release cycles, але для continuous delivery іноді буває занадто важким.

Важливо: Git Flow не є єдиним правильним workflow. Для деяких команд краще trunk-based development або простіша модель.

Develop Branch

develop branch часто використовується в Git Flow як інтеграційна гілка для майбутнього релізу.

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

завершені features;
bug fixes;
зміни для наступної версії;
інтеграційні зміни.

Проблема develop branch у деяких командах:

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

Практична порада: використовуйте develop branch тільки якщо він справді потрібен вашому release process.

Branch і CI/CD

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

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

unit tests;
integration tests;
linting;
type checks;
security scans;
build;
preview deployment;
code coverage;
static analysis.

CD може:

deploy preview для feature branch;
deploy staging для release branch;
deploy production після merge в main;
запускати rollback workflows.

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

Preview Environment

Preview environment — тимчасове середовище, створене для branch або pull request.

Воно дозволяє:

подивитися UI;
протестувати feature;
показати зміни product manager;
перевірити integration;
знайти bugs до merge;
отримати feedback.

Приклад:

feature/login-page → preview-login-page.example.com

Практична роль: preview environment дозволяє побачити branch як живий застосунок, а не тільки diff у коді.

Branch і Feature Flags

Feature flags дозволяють merge-ити код у main, але вмикати функцію окремо.

Це допомагає:

уникати довгоживучих branches;
ховати незавершену feature;
робити gradual rollout;
тестувати в production;
швидко вимикати проблемну feature;
підтримувати continuous delivery.

Практична роль: feature flag дозволяє відокремити merge коду від запуску функції для користувачів.

Branch і Release Management

Branches можуть бути частиною release process.

Моделі:

release branch для кожної версії;
tag-based releases;
main завжди production-ready;
long-term support branches;
environment branches;
hotfix branches.

Потрібно визначити:

звідки робиться release;
як робляться fixes;
як backport-яться зміни;
як ставляться tags;
як працює rollback;
хто має право merge;
які CI checks required.

Важливо: branch strategy має відповідати release strategy. Інакше команда буде боротися не з багами, а з власним workflow.

Branch і Tags

Branch і tag — різні речі.

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

Branch рухається з новими commits. Tag зазвичай лишається на одному commit.

Проста різниця: branch — це дорога, tag — це пам’ятний знак на конкретному місці дороги.

Branch і Fork

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

Поняття	Суть	Приклад
Branch	Гілка всередині repository	`feature/search`
Fork	Окрема копія repository в іншому namespace/account	fork open source project на GitHub

Fork часто використовують в open source, коли contributor не має direct write access до основного repository.

Важливо: fork може містити власні branches. Це різні рівні організації роботи.

Branch і Stash

Stash тимчасово зберігає незакомічені зміни.

Приклад:

git stash
git switch main
git stash pop

Stash корисний, якщо потрібно швидко перемкнути branch, але зміни ще не готові для commit.

Практична порада: stash зручний для короткочасного зберігання, але не варто тримати важливу роботу тільки в stash надовго.

Deleting Branch

Після merge branch часто видаляють.

Локально:

git branch -d feature/login-page

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

git branch -D feature/login-page

На remote:

git push origin --delete feature/login-page

Практична роль: видалення merged branches підтримує repository чистим і зрозумілим.

Stale Branch

Stale branch — стара гілка, яка давно не оновлювалася.

Ознаки:

останній commit був давно;
автор уже не працює над задачею;
branch сильно відстав від main;
PR неактивний;
CI давно не запускався;
задача втратила актуальність.

Stale branches створюють шум і плутанину.

Практична порада: періодично чистіть stale branches, але перед видаленням переконайтеся, що в них немає цінної роботи.

Branch Hell

Branch hell — ситуація, коли branches стало занадто багато, вони живуть занадто довго, часто конфліктують і важко інтегруються.

Ознаки:

десятки активних branches;
незрозуміло, що актуальне;
великі conflicts;
довгі code reviews;
features місяцями не merge-яться;
main сильно відрізняється від work branches;
release перетворюється на болісну інтеграцію.

Небезпека: branch hell часто з’являється, коли команда відкладає інтеграцію “на потім”. Потім приходить одразу для всіх.

Branch Strategy

Branch strategy — правила команди щодо створення, використання й об’єднання branches.

Branch strategy має визначати:

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

Практична роль: branch strategy — це правила дорожнього руху для коду.

Branch у Open Source

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

contributions;
pull requests;
bug fixes;
experiments;
release maintenance;
version support;
documentation updates.

Типовий contributor workflow:

Fork repository
  ↓
Create branch
  ↓
Commit changes
  ↓
Push branch to fork
  ↓
Open pull request

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

Branch у Documentation

Branches корисні не тільки для коду, а й для документації.

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

оновлювати docs разом із feature;
готувати release notes;
тримати docs для різних версій;
review-ити documentation changes;
генерувати preview docs;
підтримувати long-term versions.

Приклади:

docs/api-auth
docs/v2-migration-guide
release/docs-1.5

Практична роль: якщо код змінюється в branch, документація до нього теж може змінюватися в тому самому branch.

Branch у Data і ML-проєктах

У data science і machine learning branches використовують для:

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

Але великі datasets і model artifacts не завжди зручно зберігати прямо в Git branches. Для цього часто використовують окреме versioning або artifact storage.

Важливо: branch добре версіонує код, але не завжди підходить для великих binary artifacts або datasets.

Branch у CI Preview для Frontend

Frontend-команди часто створюють preview deployment для кожного branch або pull request.

Це зручно для:

UI review;
дизайнерського feedback;
product review;
accessibility checks;
visual regression testing;
stakeholder demo;
QA до merge.

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

Branch і Security

Branches можуть впливати на безпеку.

Потрібно контролювати:

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

Критично: branch із pull request може запускати CI. Треба обережно налаштовувати доступ до secrets, особливо для зовнішніх contributors.

Branch і Secrets

Не можна commit-ити secrets у branch.

До secrets належать:

API keys;
passwords;
private keys;
tokens;
cloud credentials;
database URLs із паролем;
signing keys;
OAuth secrets.

Якщо secret потрапив у branch:

видалити файл недостатньо;
потрібно rotate secret;
перевірити history;
перевірити logs і CI;
за потреби переписати history;
повідомити команду безпеки.

Критично: якщо secret був у Git branch, вважайте його скомпрометованим, навіть якщо branch потім видалили.

Переваги Branch

Основні переваги branches:

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

Головна перевага: branch дозволяє рухатися швидко, але не змішувати незавершену роботу зі стабільним кодом.

Ризики Branch

Branches мають ризики.

Можливі проблеми:

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

Помилка: створити branch легко. Складніше — вчасно інтегрувати його назад або чесно видалити.

Коли варто створювати Branch

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

починається нова feature;
потрібно виправити bug;
потрібен hotfix;
треба підготувати release;
хочеться протестувати ідею;
зміна потребує code review;
робота займе більше одного commit;
потрібно запустити CI окремо;
зміна ризикована;
ви працюєте в команді.

Практична порада: якщо зміна не має потрапити в main прямо зараз, краще зробити branch.

Коли Branch може бути зайвим

Branch може бути зайвим, якщо:

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

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

Важливо: branch — інструмент. Його не треба створювати ритуально для кожного символу, але для більшості командних змін він дуже корисний.

Хороші практики Branch

Рекомендовано:

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

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

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

Поширені помилки:

працювати прямо в 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. Перед роботою завжди корисно зробити `git status`.

Цікаві факти про Branch

У Git branch — це легкий pointer на commit, а не повна копія repository.
Branch дозволяє експериментувати без ризику для main.
Merge conflict — не помилка Git, а сигнал, що потрібне людське рішення.
Long-lived branches часто створюють більше проблем, ніж здається на старті.
Pull request — це не тільки технічний merge, а й інструмент командної комунікації.
Feature flags допомагають зменшити потребу в довгоживучих branches.
`main` і `master` можуть виконувати ту саму роль, але в різних проєктах називатися по-різному.
Stale branches — це цифровий пил repository.
Branch protection — один із найпростіших способів захистити команду від випадкового зламу main.
Найкращі branches часто маленькі, зрозумілі й швидко merge-яться.

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

Приклади сценаріїв використання

Нова функція

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

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

Команда створює `hotfix/checkout-error`, виправляє payment issue, запускає CI й швидко deploy-ить fix.

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

Створюється `release/2.3.0`, у якому роблять final fixes, оновлюють changelog і готують deployment.

Експеримент

Розробник створює `experiment/new-search-engine`, перевіряє підхід і після тестів або переносить ідею в normal branch, або видаляє експеримент.

Документація

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

Підказка: branch має відповідати одній зрозумілій задачі. Якщо в ньому вже три різні задачі, краще розділити роботу.

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

git switch main
git pull origin main

git switch -c feature/profile-settings

# edit files

git add .
git commit -m "Add profile settings page"

git push -u origin feature/profile-settings

Після цього зазвичай створюється pull request.

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

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

git switch feature/profile-settings
git pull origin main

Якщо виник conflict:

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

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

title: "Account settings"

Потім:

git add .
git commit

Важливо: після conflict обов’язково запускайте tests. Конфлікт можна вирішити синтаксично правильно, але логічно неправильно.

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

Branch створено від актуального main
Назва branch зрозуміла
Branch відповідає одній задачі
Commits мають зрозумілі повідомлення
Немає secrets
Тести проходять
CI зелений
PR описує що і навіщо змінено
Branch не відстав сильно від main
Merge conflicts вирішені уважно
Після merge branch можна видалити

Практична роль: checklist допомагає зробити branch не просто місцем для коду, а чистою частиною командного workflow.

Джерела

Документація Git щодо branches, commits, merge, rebase і remote branches.
Документація GitHub, GitLab і Bitbucket щодо pull requests, merge requests і branch protection.
Практики software development щодо branching strategies, Git Flow, trunk-based development і CI/CD.
Матеріали щодо code review, release management, feature flags, DevOps, secure development і version control workflows.

Висновок

Branch — це гілка розробки в системі контролю версій, яка дозволяє ізолювати зміни, працювати паралельно, робити code review, запускати CI й безпечніше інтегрувати новий код. У Git branch є легким pointer на commit, тому branches швидко створюються й активно використовуються в командній роботі.

Branches особливо корисні для features, bug fixes, hotfixes, releases, experiments і documentation changes. Водночас вони потребують дисципліни: зрозумілі назви, короткий життєвий цикл, регулярна інтеграція, branch protection, CI checks і обережне вирішення conflicts.

Головна думка: branch — це безпечна робоча зона для змін. Він має допомагати команді швидше й чистіше інтегрувати код, а не створювати хаос із десятків забутих гілок.

Цікавий факт

Загальний опис

Branch у Git

Main Branch

Master Branch

Feature Branch

Bugfix Branch

Hotfix Branch

Release Branch

Experimental Branch

Local Branch і Remote Branch

Створення Branch

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

Commit у Branch

Push Branch

Pull Request

Merge Request

Merge

Fast-Forward Merge

Rebase

Merge vs Rebase

Merge Conflict

Branch Protection

Branch Naming Conventions

Long-Lived Branch

Short-Lived Branch

Trunk-Based Development

Git Flow

Develop Branch

Branch і CI/CD

Preview Environment

Branch і Feature Flags

Branch і Release Management

Branch і Tags

Branch і Fork

Branch і Stash

Deleting Branch

Stale Branch

Branch Hell

Branch Strategy

Branch у Open Source

Branch у Documentation

Branch у Data і ML-проєктах

Branch у CI Preview для Frontend

Branch і Security

Branch і Secrets

Переваги Branch

Ризики Branch

Коли варто створювати Branch

Коли Branch може бути зайвим

Хороші практики Branch

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

Цікаві факти про Branch

Приклади сценаріїв використання

Нова функція

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

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

Експеримент

Документація

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

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

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

Джерела

Висновок

Див. також

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