Develop Branch у Git — що це, призначення та принцип роботи

Що таке Develop Branch у Git

Develop Branch (гілка розробки) — це довгоживуча гілка в Git Flow, яка служить центральним вузлом для інтеграції коду від усіх розробників. У неї зливаються feature гілки після завершення розробки та проходження код-рев'ю.

Код у develop завжди знаходиться в стані, готовому до створення релізу, хоча ще не випущений у продакшн. Це означає, що всі функції в develop пройшли рев'ю, тестування та інтеграційні перевірки, але ще очікують свого релізного циклу.

На відміну від main, де кожна версія коду — це реліз, develop містить безперервний потік змін. Коміти в develop з'являються в міру злиття feature гілок, що може відбуватися кілька разів на день.

За даними Vincent Driessen, 2010, develop є ключовим елементом успішної моделі гілкування, оскільки відокремлює чернову роботу від готових до випуску версій.

Відмінності develop від main branch

Розуміння відмінностей між develop та main критично важливе для правильної роботи в Git Flow. Ці гілки виконують різні функції та мають різні вимоги до стабільності.

Розділення на develop та main дозволяє команді безперервно інтегрувати новий код, не ризикуючи стабільністю продакшен-версії. Розробники можуть бачити свій код у develop одразу після затвердження PR, навіть до офіційного релізу.

Роль develop у Git Flow

У моделі Git Flow develop займає центральне місце між feature гілками (джерело змін) та release гілками (підготовка до випуску). Розуміння цієї ієрархії — основа ефективного гілкування.

• Feature → Develop — кожна завершена функція зливається в develop через Pull Request з код-рев'ю.
• Develop → Release — коли набирається достатній обсяг змін для релізу, від develop створюється release гілка.
• Release → Main + Develop — після фінальної підготовки release гілка зливається в main (реліз) та назад у develop (багфікси).
• Hotfix → Main + Develop — критичні виправлення створюються від main і зливаються в обидві гілки.

Така структура гарантує, що develop завжди містить останню версію коду з усіма новими функціями, а main — тільки перевірений продакшен-код. Це особливо важливо для мобільних проектів з тривалим циклом рев'ю в App Store та Google Play.

Зв'язок develop з іншими гілками Git Flow

Develop виступає центральною ланкою між feature, release та hotfix гілками. Розуміння напрямків злиття — основа для запобігання конфліктам та втраті комітів.

Вимоги до якості коду в develop

Якість коду в develop має бути високою, але не абсолютною. На відміну від main, де кожна помилка означає терміновий hotfix, develop допускає незначні недоробки, які будуть виправлені до релізу.

Мінімальні вимоги до коду перед злиттям у develop:

• Компіляція — код має компілюватися без помилок. Зламана збірка в develop блокує роботу всієї команди.
• Юніт-тести — всі існуючі тести мають проходити. Новий код має бути покритий тестами мінімум на 70%.
• Code style — код має відповідати прийнятим у команді стандартам форматування та неймінгу.
• Відсутність deprecated API — використання застарілих методів не допускається в новому коді.

Автоматичні перевірки в CI/CD пайплайні мають запускатися на кожен push у develop. Якщо збірка ламається, відповідальний розробник зобов'язаний виправити проблему протягом години або відкотити свій коміт.

CI/CD перевірки для develop

Налаштування GitHub Actions для develop гарантує, що кожен PR перед злиттям проходить автоматичну перевірку. Типовий пайплайн включає збірку, тести та лінтинг.

# GitHub Actions — перевірка develop після злиття
name: Develop CI

on:
  pull_request:
    branches: [develop]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Unit tests
        run: ./gradlew testDebug
      - name: Lint
        run: ./gradlew lint
      - name: Build
        run: ./gradlew assembleDebug

Правила злиття в develop

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

• Тільки через Pull Request — прямий push у develop заборонений. Всі зміни проходять код-рев'ю.
• Мінімум один approve — PR має отримати затвердження як мінімум від одного розробника, який не брав участі в задачі.
• Squash merge — рекомендується об'єднувати всі коміти feature гілки в один при злитті в develop для чистої історії.
• Актуальність PR — перед злиттям PR має бути оновлений відносно останнього коміту develop (rebase або merge).

Правило актуальності PR особливо важливе. Якщо feature гілка створена тиждень тому, а develop пішов вперед на 50 комітів, пряме злиття може призвести до конфліктів, які краще вирішити в контексті PR, а не в develop.

Захист develop від некоректних злиттів

Branch protection rules (правила захисту гілки) — це налаштування на рівні GitHub, GitLab або Bitbucket, які запобігають некоректним змінам у develop. Вони гарантують, що навіть випадковий push не зламає інтеграційну гілку.

Рекомендовані правила захисту для develop:

• Require pull request — заборонити прямий push у develop. Всі зміни тільки через PR.
• Require approvals — мінімум 1-2 approve перед злиттям PR.
• Require status checks — блокувати злиття, якщо CI/CD пайплайн не пройшов.
• Require up-to-date — гілка PR має бути оновлена відносно develop перед злиттям.
• Restrict push access — обмежити права на push у develop тільки для senior розробників.

Налаштування захисту develop займає 10 хвилин, але запобігає тижням простоїв, пов'язаних зі зламаною інтеграційною гілкою. Для мобільних проектів з багатоплатформними командами це особливо актуально.

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

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

# Ранкова синхронізація develop
git checkout develop
git pull origin develop

# Створення нової feature гілки від develop
git checkout -b feature/add-push-notifications

# Робота над функцією...
git add . && git commit -m "Add FCM integration"

# Оновлення develop під час розробки
git fetch origin develop
git rebase origin/develop

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

Команда git pull у develop виконує одразу дві операції: git fetch (забирає нові коміти з сервера) та git merge (зливає їх з локальною гілкою). Для develop це стандартний спосіб синхронізації.

Відновлення develop після зламаного злиття

Якщо в develop потрапив код, який зламав збірку, діяти потрібно швидко. Кожна година простою develop — це заблокована робота всієї команди розробників.

Якщо в develop потрапив код, який зламав збірку, використовуйте git revert для створення нового коміту, що скасовує проблемні зміни. Не використовуйте git reset у develop — це переписує історію, яка вже є в інших учасників.

# Пошук проблемного коміту
git log --oneline develop

# Скасування коміту через revert (безпечно)
git revert a1b2c3d

# Відправка виправлення у віддалений develop
git push origin develop

# Перегляд змін у конкретному коміті
git show a1b2c3d --stat