Develop Branch v Gitu — co to je, účel a princip fungování

Co je Develop Branch v Gitu

Develop Branch (vývojová větev) — je dlouhožijící větev v Git Flow, která slouží jako centrální uzel pro integraci kódu od všech vývojářů. Feature větve se do ní slučují po dokončení vývoje a absolvování code review.

Kód v develop je vždy ve stavu připraveném k vytvoření vydání, i když ještě nebyl publikován do produkce. To znamená, že všechny funkce v develop prošly review, testováním a integračními kontrolami, ale stále čekají na svůj cyklus vydání.

Na rozdíl od main, kde každá verze kódu je vydáním, develop obsahuje nepřetržitý tok změn. Commity v develop se objevují s postupným slučováním feature větví, což může nastat několikrát denně.

Podle údajů Vincent Driessen, 2010 je develop klíčovým prvkem úspěšného modelu větvení, protože odděluje rozpracovanou práci od verzí připravených k vydání.

Rozdíly mezi develop a main branch

Porozumění rozdílům mezi develop a main je kriticky důležité pro správnou práci v Git Flow. Tyto větve plní různé funkce a mají různé požadavky na stabilitu.

Rozdělení na develop a main umožňuje týmu průběžně integrovat nový kód bez rizika pro stabilitu produkční verze. Vývojáři mohou vidět svůj kód v develop ihned po schválení PR, ještě před oficiálním vydáním.

Role develop v Git Flow

V modelu Git Flow zaujímá develop centrální místo mezi feature větvemi (zdroj změn) a release větvemi (příprava na vydání). Pochopení této hierarchie je základem efektivního větvení.

• Feature → Develop — každá dokončená funkce se sloučí do develop pomocí Pull Request s code review.
• Develop → Release — když se nashromáždí dostatečný objem změn pro vydání, z develop se vytvoří release větev.
• Release → Main + Develop — po konečné přípravě se release větev sloučí do main (vydání) a zpět do develop (opravy chyb).
• Hotfix → Main + Develop — kritické opravy se vytvářejí z main a slučují se do obou větví.

Taková struktura zaručuje, že develop vždy obsahuje nejnovější verzi kódu se všemi novými funkcemi, a main — pouze ověřený produkční kód. To je obzvláště důležité pro mobilní projekty s dlouhým cyklem review v App Store a Google Play.

Spojení develop s ostatními větvemi Git Flow

Develop funguje jako centrální článek mezi feature, release a hotfix větvemi. Pochopení směrů slučování je základem prevence konfliktů a ztráty commitů.

Požadavky na kvalitu kódu v develop

Kvalita kódu v develop musí být vysoká, ale ne absolutní. Na rozdíl od main, kde každá chyba znamená naléhavý hotfix, develop umožňuje menší nedostatky, které budou opraveny před vydáním.

Minimální požadavky na kód před sloučením do develop:

• Kompilace — kód se musí kompilovat bez chyb. Rozbitá kompilace v develop blokuje práci celého týmu.
• Unit testy — všechny existující testy musí procházet. Nový kód musí být pokryt testy minimálně ze 70%.
• Code style — kód musí odpovídat standardům formátování a pojmenování přijatým v týmu.
• Žádná zastaralá API — používání zastaralých metod není v novém kódu povoleno.

Automatické kontroly v CI/CD pipeline by se měly spouštět při každém pushi do develop. Pokud se kompilace rozbije, odpovědný vývojář musí problém opravit do hodiny nebo vrátit svůj commit.

CI/CD kontroly pro develop

Nastavení GitHub Actions pro develop zaručuje, že každý PR před sloučením projde automatickou kontrolou. Typická pipeline zahrnuje kompilaci, testy a linting.

# GitHub Actions — kontrola develop po sloučení
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

Pravidla slučování do develop

Sloučení do develop musí podléhat přísným pravidlům pro udržení stability integrační větve. Porušení těchto pravidel vede ke konfliktům, rozbitým kompilacím a ztrátě času týmu.

• Pouze přes Pull Request — přímý push do develop je zakázán. Všechny změny procházejí code review.
• Minimálně jeden approve — PR musí získat schválení od alespoň jednoho vývojáře, který se neúčastnil úkolu.
• Squash merge — doporučuje se sloučit všechny commity feature větve do jednoho při sloučení do develop pro čistou historii.
• Aktuálnost PR — před sloučením musí být PR aktualizován vůči poslednímu commitu develop (rebase nebo merge).

Pravidlo aktuálnosti PR je obzvláště důležité. Pokud byla feature větev vytvořena před týdnem a develop postoupil o 50 commitů, přímé sloučení může vést ke konfliktům, které je lépe vyřešit v kontextu PR, ne v develop.

Ochrana develop před nesprávným slučováním

Branch protection rules (pravidla ochrany větve) — nastavení na úrovni GitHub, GitLab nebo Bitbucket, která zabraňují nesprávným změnám v develop. Zaručují, že ani náhodný push nerozbije integrační větev.

Doporučená pravidla ochrany pro develop:

• Require pull request — zakázat přímý push do develop. Všechny změny pouze přes PR.
• Require approvals — minimálně 1-2 schválení před sloučením PR.
• Require status checks — blokovat sloučení, pokud CI/CD pipeline neprošel.
• Require up-to-date — větev PR musí být aktualizována vůči develop před sloučením.
• Restrict push access — omezit práva push do develop pouze pro senior vývojáře.

Nastavení ochrany develop trvá 10 minut, ale předchází týdnům prostojů spojených s rozbitou integrační větví. Pro mobilní projekty s multiplatformními týmy je to obzvláště důležité.

Příklady příkazů pro práci s develop

Podívejme se na typický den vývojáře: ráno aktualizuje develop, vytvoří novou feature větev a po dokončení úkolu sloučí změny zpět do develop.

# Ranní synchronizace develop
git checkout develop
git pull origin develop

# Vytvoření nové feature větve z develop
git checkout -b feature/add-push-notifications

# Práce na funkci...
git add . && git commit -m "Add FCM integration"

# Aktualizace develop během vývoje
git fetch origin develop
git rebase origin/develop

# Po schválení PR — aktualizace lokálního develop
git checkout develop
git pull origin develop
git branch -d feature/add-push-notifications

Příkaz git pull v develop provádí současně dvě operace: git fetch (stahuje nové commity ze serveru) a git merge (slučuje je s místní větví). Pro develop je to standardní způsob synchronizace.

Obnovení develop po rozbitém sloučení

Pokud se do develop dostal kód, který rozbil kompilaci, je třeba jednat rychle. Každá hodina prostoje develop znamená blokovanou práci celého vývojářského týmu.

Pokud se do develop dostal kód, který rozbil kompilaci, použijte git revert k vytvoření nového commitu, který ruší problematické změny. Nepoužívejte git reset v develop — to přepisuje historii, která již existuje u ostatních účastníků.

# Nalezení problematického commitu
git log --oneline develop

# Zrušení commitu pomocí revert (bezpečné)
git revert a1b2c3d

# Odeslání opravy do vzdáleného develop
git push origin develop

# Zobrazení změn v konkrétním commitu
git show a1b2c3d --stat