Develop Branch a Git-ben — mi ez, célja és működési elve

Mi az a Develop Branch a Git-ben

Develop Branch (fejlesztési ág) — egy hosszú életű ág a Git Flow-ban, amely központi csomópontként szolgál az összes fejlesztő kódjának integrációjához. A feature ágak a fejlesztés befejezése és a code review-n való átesés után olvadnak bele.

A develop-ban lévő kód mindig kiadásra kész állapotban van, bár még nem került kiadásra a termelésben. Ez azt jelenti, hogy a develop-ban lévő összes funkció átesett review-n, tesztelésen és integrációs ellenőrzéseken, de még vár a kiadási ciklusára.

A main-től eltérően, ahol minden kódverzió egy kiadás, a develop folyamatos változásáramlást tartalmaz. A commitok a develop-ban a feature ágak beolvadásával jelennek meg, ami naponta többször is megtörténhet.

Vincent Driessen, 2010 adatai szerint a develop egy sikeres elágazási modell kulcseleme, mivel elválasztja a folyamatban lévő munkát a kiadásra kész verzióktól.

Különbségek a develop és a main branch között

A develop és a main közötti különbségek megértése kritikus fontosságú a Git Flow-ban való helyes munkához. Ezek az ágak különböző funkciókat látnak el, és eltérő stabilitási követelményekkel rendelkeznek.

A develop és main szétválasztása lehetővé teszi a csapat számára az új kód folyamatos integrációját anélkül, hogy kockáztatná a termelési verzió stabilitását. A fejlesztők láthatják a kódjukat a develop-ban közvetlenül a PR jóváhagyása után, még a hivatalos kiadás előtt.

A develop szerepe a Git Flow-ban

A Git Flow modellben a develop központi helyet foglal el a feature ágak (változások forrása) és a release ágak (kiadás előkészítése) között. Ennek a hierarchiának a megértése a hatékony elágazás alapja.

• Feature → Develop — minden befejezett funkció Pull Request-en keresztül code review-val olvad be a develop-ba.
• Develop → Release — amikor elegendő változás gyűlt össze egy kiadáshoz, a release ág a develop-ból jön létre.
• Release → Main + Develop — a végső előkészítés után a release ág beolvad a main-be (kiadás) és vissza a develop-ba (hibajavítások).
• Hotfix → Main + Develop — kritikus javítások a main-ből jönnek létre, és mindkét ágba beolvadnak.

Ez a struktúra garantálja, hogy a develop mindig a legújabb kódverziót tartalmazza az összes új funkcióval, a main pedig csak ellenőrzött termelési kódot. Ez különösen fontos a hosszú review-ciklusú mobil projekteknél az App Store-ban és a Google Play-ben.

A develop kapcsolata más Git Flow ágakkal

A develop központi láncszemként működik a feature, release és hotfix ágak között. A beolvadási irányok megértése az alapja a konfliktusok és a commitok elvesztésének megelőzésének.

Kódminőségi követelmények a develop-ban

Kódminőség a develop-ban magas kell legyen, de nem abszolút. A main-től eltérően, ahol minden hiba sürgős hotfix-et jelent, a develop megengedi a kisebb hiányosságokat, amelyeket a kiadás előtt kijavítanak.

Minimális követelmények a kóddal szemben a develop-ba való beolvadás előtt:

• Fordítás — a kódnak hiba nélkül kell fordulnia. A törött fordítás a develop-ban blokkolja az egész csapat munkáját.
• Unit tesztek — az összes meglévő tesztnek át kell mennie. Az új kódot legalább 70%-ban le kell fedniük a teszteknek.
• Code style — a kódnak meg kell felelnie a csapatban elfogadott formázási és elnevezési szabványoknak.
• Nincs elavult API — elavult metódusok használata nem megengedett az új kódban.

Az automatikus ellenőrzések a CI/CD pipeline-ban minden push-kor futniuk kell a develop-ba. Ha a fordítás elromlik, a felelős fejlesztőnek egy órán belül meg kell javítania a problémát, vagy vissza kell vonnia a commitját.

CI/CD ellenőrzések a develop számára

A GitHub Actions beállítása a develop számára garantálja, hogy minden PR a beolvadás előtt automatikus ellenőrzésen megy keresztül. A tipikus pipeline tartalmazza a fordítást, teszteket és lintinget.

# GitHub Actions — develop ellenőrzése beolvadás után
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

Beolvadási szabályok a develop-ba

Beolvadás a develop-ba szigorú szabályoknak kell alávetnie magát az integrációs ág stabilitásának fenntartása érdekében. E szabályok megsértése konfliktusokhoz, törött fordításokhoz és a csapat időveszteségéhez vezet.

• Csak Pull Request-en keresztül — a közvetlen push a develop-ba tilos. Minden változás code review-n megy keresztül.
• Minimum egy jóváhagyás — a PR-nek legalább egy olyan fejlesztő jóváhagyását kell megkapnia, aki nem vett részt a feladatban.
• Squash merge — ajánlott a feature ág összes commitját egyesíteni a develop-ba való beolvadáskor a tiszta történet érdekében.
• PR aktualitása — a beolvadás előtt a PR-t frissíteni kell a develop legutolsó commitjához képest (rebase vagy merge).

A PR aktualitásának szabálya különösen fontos. Ha a feature ág egy hete jött létre, és a develop 50 commit-tal előrébb jár, a közvetlen beolvadás konfliktusokhoz vezethet, amelyeket jobb a PR kontextusában megoldani, nem a develop-ban.

A develop védelme helytelen beolvadásoktól

Branch protection rules (ágvédelmi szabályok) — GitHub, GitLab vagy Bitbucket szintű beállítások, amelyek megakadályozzák a helytelen változtatásokat a develop-ban. Garantálják, hogy még egy véletlen push sem töri el az integrációs ágat.

Ajánlott védelmi szabályok a develop számára:

• Require pull request — tiltsa le a közvetlen push-t a develop-ba. Minden változás csak PR-en keresztül.
• Require approvals — minimum 1-2 jóváhagyás a PR beolvadása előtt.
• Require status checks — blokkolja a beolvadást, ha a CI/CD pipeline nem ment át.
• Require up-to-date — a PR ágnak frissíteni kell a develop-hoz képest a beolvadás előtt.
• Restrict push access — korlátozza a push jogokat a develop-ba csak senior fejlesztőkre.

A develop védelmének beállítása 10 percet vesz igénybe, de megelőzi a törött integrációs ággal kapcsolatos hetekig tartó állásidőt. A többplatformos csapatokkal rendelkező mobil projekteknél ez különösen fontos.

Példák parancsokra a develop-pal való munkához

Tekintsünk át egy tipikus fejlesztői napot: reggel frissíti a develop-ot, létrehoz egy új feature ágat, és a feladat befejezése után visszaolvasztja a változtatásokat a develop-ba.

# Reggeli develop szinkronizáció
git checkout develop
git pull origin develop

# Új feature ág létrehozása a develop-ból
git checkout -b feature/add-push-notifications

# Munka a funkción...
git add . && git commit -m "Add FCM integration"

# Develop frissítése fejlesztés közben
git fetch origin develop
git rebase origin/develop

# PR jóváhagyása után — helyi develop frissítése
git checkout develop
git pull origin develop
git branch -d feature/add-push-notifications

A git pull parancs a develop-ban egyszerre két műveletet hajt végre: git fetch (új commitok letöltése a szerverről) és git merge (egyesítés a helyi ággal). A develop esetében ez a szinkronizáció szokásos módja.

A develop helyreállítása törött beolvadás után

Ha olyan kód került a develop-ba, amely eltörte a fordítást, gyorsan kell cselekedni. A develop minden órányi állásideje a fejlesztői csapat egészének blokkolt munkáját jelenti.

Ha olyan kód került a develop-ba, amely eltörte a fordítást, használja a git revert-et egy új commit létrehozásához, amely visszavonja a problémás változtatásokat. Ne használja a git reset-et a develop-ban — ez felülírja a történetet, amely már más résztvevőknél is létezik.

# Problémás commit megtalálása
git log --oneline develop

# Commit visszavonása revert-tel (biztonságos)
git revert a1b2c3d

# Javítás küldése a távoli develop-ba
git push origin develop

# Változások megtekintése egy adott commit-ban
git show a1b2c3d --stat