Develop Branch в Git — какво е, предназначение и принцип на работа

Какво е Develop Branch в Git

Develop Branch (клон за разработка) — дългоживеещ клон в Git Flow, който служи като централен възел за интеграция на код от всички разработчици. Feature клоновете се сливат в него след завършване на разработката и преминаване през code review.

Кодът в 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 с code review.
• 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 — кодът трябва да отговаря на приетите в екипа стандарти за форматиране и именуване.
• Без остарели 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 е забранен. Всички промени преминават code review.
• Минимум едно одобрение — 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 одобрения преди сливане на PR.
• Require status checks — блокирай сливане, ако CI/CD пайплайнът не е преминал.
• Require up-to-date — PR клонът трябва да бъде актуализиран спрямо develop преди сливане.
• Restrict push access — ограничи правата за push в develop само за старши разработчици.

Конфигурирането на защита на 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