Feature Branch у Git: що це, як створити та працювати з гілками

Що таке Feature Branch у Git

Feature Branch (гілка функції) — це тимчасова гілка в Git, створена від develop для розробки окремої функціональності. На відміну від довгоживучих гілок main і develop, feature гілки існують обмежений час — від кількох годин до кількох тижнів.

Основна мета feature branch — ізолювати зміни, пов'язані з одним завданням, від решти коду. Розробник може експериментувати, робити безліч комітів і навіть ламати код у своїй гілці, не впливаючи на роботу інших учасників команди.

Після завершення розробки feature branch зливається назад у develop через Pull Request з обов'язковим код-рев'ю. Після злиття гілка зазвичай видаляється, щоб репозиторій залишався чистим.

За даними Vincent Driessen, 2010, модель Git Flow із feature гілками стала стандартом індустрії завдяки чіткому розподілу відповідальності між різними типами гілок.

Робочий процес із Feature Branch

Робочий процес із feature branch складається з послідовності кроків, які розробник виконує для кожної нової функції. Цей процес мінімізує конфлікти злиття та забезпечує контроль якості коду.

1. Створення гілки від останнього коміту develop. Розробник перемикається на develop, оновлює його та створює нову feature гілку.
2. Розробка та коміти у feature гілку. Розробник вносить зміни, робить коміти зі зрозумілими описами та періодично пушить гілку у віддалений репозиторій.
3. Синхронізація з develop — під час розробки основна гілка може піти вперед. Розробник виконує rebase або merge develop у свою feature гілку.
4. Створення Pull Request — коли функція готова, розробник відкриває PR для код-рев'ю. Команда перевіряє код і залишає коментарі.
5. Злиття та видалення — після затвердження PR гілка зливається в develop і видаляється як локально, так і віддалено.

Періодична синхронізація з develop критично важлива. Чим довше живе feature гілка без злиття змін із develop, тим вища ймовірність конфліктів при фінальному злитті.

Частота синхронізації feature гілки

Правила іменування гілок feature

Іменування гілок — важлива частина командної дисципліни. Єдиний стандарт назв дозволяє швидко визначити, над яким завданням ведеться робота та хто її виконує.

• feature/назва — префікс feature/ використовується в класичному Git Flow. Приклад: feature/added-auth-module.
• feature/JIRA-123-опис — прив'язка до номера завдання в системі відстеження. Приклад: feature/PROJ-42-add-login.
• feature/тип/назва — розширений формат із зазначенням типу завдання. Приклад: feature/feat/analytics-dashboard.

Використання ID завдання з JIRA, Trello або іншої системи — найкраща практика. Вона автоматично пов'язує код із завданням і спрощує пошук гілок через git log.

Процес Pull Request

Pull Request (або Merge Request у GitLab) — це запит на злиття feature гілки в develop. PR — не просто технічна операція, а процес командного код-рев'ю, який підвищує якість коду та поширює знання всередині команди.

Хороший PR містить заголовок із коротким описом завдання, посилання на тікет і опис змін. Розробник має вказати, що саме було зроблено, які файли змінено та чи є потенційні ризики для інших частин проєкту.

Команда переглядає код у PR, залишає коментарі, запитує зміни (change requests) і затверджує злиття (approve). Після затвердження PR виконується merge або squash merge.

Середній час перевірки PR у мобільній розробці — від 4 до 24 годин. Бібліотека Danger автоматизує частину перевірок, запускаючи лінтери та тести безпосередньо в PR.

Рекомендації щодо створення хорошого PR

• Розмір — не більше 300-400 рядків змін. Великі PR складно рев'юїти, якість перевірки падає.
• Один PR — одне завдання — уникайте змішування непов'язаних змін в одному запиті.
• Скріншоти — для UI-змін додавайте скріншоти до та після.
• Тести — для нової функціональності пишіть юніт-тести та включайте їх у PR.

Стратегії злиття гілок feature

Після затвердження PR feature гілка може бути злита в develop різними способами. Вибір стратегії злиття впливає на історію комітів і можливість відкату змін.

• Merge commit — створює коміт злиття, зберігаючи всю історію комітів feature гілки. Історія залишається повною, але граф гілок стає складнішим.
• Squash merge — об'єднує всі коміти feature гілки в один і додає його поверх develop. Історія стає чистішою, але інформація про проміжні коміти втрачається.
• Rebase and merge — переписує коміти feature гілки поверх останнього коміту develop і зливає без додаткового коміту. Історія залишається лінійною.

Для мобільних проєктів із частими релізами найчастіше використовують squash merge: він дає чисту історію в develop, а деталі розробки залишаються в описі PR і в завданні трекера.

Типові помилки під час роботи з Feature Branch

Навіть досвідчені розробники припускаються помилок під час роботи з feature гілками. Знання типових проблем допомагає уникнути втрати часу та даних.

• Занадто довге життя гілки — feature гілка живе довше 2-3 тижнів без синхронізації з develop, що призводить до масивних конфліктів злиття.
• Коміти з незрозумілими описами — повідомлення типу «fix» або «update» не дають зрозуміти, що було змінено та навіщо.
• Змішування завдань — в одній feature гілці розробляються дві непов'язані функції, що робить неможливим вибірковий відкат.
• Відсутність синхронізації — розробник не робить git fetch і не оновлює develop, через що при фінальному merge виникають конфлікти.

Найкращий спосіб уникнути цих проблем — домовитися про правила роботи на старті проєкту та використовувати автоматичні перевірки в CI/CD пайплайні.

Приклади команд для роботи з Feature Branch

Розглянемо практичний сценарій: розробник починає нову функцію авторизації в мобільному додатку. Він створює feature гілку, працює над кодом і завершує завдання Pull Request.

# Оновлення develop і створення feature гілки
git checkout develop
git pull origin develop
git checkout -b feature/add-login-screen

# Робота над функцією: коміти
git add src/ui/login/
git commit -m "Add login screen layout"

# Відправка feature гілки на сервер
git push origin feature/add-login-screen

# Синхронізація з develop (rebase)
git fetch origin develop
git rebase origin/develop

# Після затвердження PR: оновлення локального develop і видалення гілки
git checkout develop
git pull origin develop
git branch -d feature/add-login-screen

Команда git branch -d видаляє гілку тільки після того, як її зміни повністю злиті. Якщо гілка не злита, Git запропонує використати git branch -D для примусового видалення — використовуйте цей прапорець з обережністю.

Автоматизація перевірок у feature гілці

CI/CD пайплайн має запускатися для кожної feature гілки перед створенням PR. Це дозволяє виявити проблеми на ранній стадії, до того як код потрапить на рев'ю іншим розробникам.

# GitHub Actions для перевірки feature гілки
name: Feature Branch CI

on:
  push:
    branches:
      - 'feature/**'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: ./gradlew test
      - name: Lint check
        run: ./gradlew lint

Пайплайн перевіряє, що код компілюється, тести проходять і стиль коду відповідає прийнятим у команді стандартам. Тільки після проходження всіх перевірок можна створювати Pull Request.