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 гране

Разумевање разлика између 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-а, где свака грешка значи хитну исправку, 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