Develop Branch in Git — wat het is, doel en werkingsprincipe

Wat is Develop Branch in Git

Develop Branch (ontwikkeltak) — een langlevende tak in Git Flow die dient als centraal knooppunt voor integratie van code van alle ontwikkelaars. Feature-takken worden erin samengevoegd na voltooiing van de ontwikkeling en het doorlopen van code review.

Code in develop bevindt zich altijd in een staat die klaar is voor het maken van een release, hoewel het nog niet in productie is uitgebracht. Dit betekent dat alle functies in develop review, testen en integratiecontroles hebben doorlopen, maar nog wachten op hun releasecyclus.

In tegenstelling tot main, waar elke codeversie een release is, bevat develop een continue stroom van wijzigingen. Commits in develop verschijnen naarmate feature-takken worden samengevoegd, wat meerdere keren per dag kan gebeuren.

Volgens Vincent Driessen, 2010 is develop een sleutelelement van een succesvol vertakkingsmodel, omdat het werk-in-uitvoering scheidt van versies die klaar zijn voor release.

Verschillen tussen develop en main branch

Het begrijpen van de verschillen tussen develop en main is van cruciaal belang voor correct werken in Git Flow. Deze takken vervullen verschillende functies en hebben verschillende stabiliteitseisen.

De scheiding in develop en main stelt het team in staat continu nieuwe code te integreren zonder de stabiliteit van de productieversie in gevaar te brengen. Ontwikkelaars kunnen hun code in develop zien direct na goedkeuring van de PR, zelfs vóór de officiële release.

Rol van develop in Git Flow

In het Git Flow-model neemt develop een centrale plaats in tussen feature-takken (bron van wijzigingen) en release-takken (voorbereiding op uitgave). Begrip van deze hiërarchie is de basis van effectief vertakken.

• Feature → Develop — elke voltooide functie wordt via een Pull Request met code review in develop samengevoegd.
• Develop → Release — wanneer er voldoende wijzigingen voor een release zijn verzameld, wordt vanuit develop een release-tak gemaakt.
• Release → Main + Develop — na de definitieve voorbereiding wordt de release-tak samengevoegd in main (release) en terug in develop (bugfixes).
• Hotfix → Main + Develop — kritieke fixes worden gemaakt vanuit main en samengevoegd in beide takken.

Een dergelijke structuur garandeert dat develop altijd de nieuwste codeversie met alle nieuwe functies bevat, en main — alleen gevalideerde productiecode. Dit is vooral belangrijk voor mobiele projecten met een lange reviewcyclus in de App Store en Google Play.

Relatie van develop met andere Git Flow-takken

Develop fungeert als centrale schakel tussen feature-, release- en hotfix-takken. Begrip van de samenvoegrichtingen is de basis voor het voorkomen van conflicten en verlies van commits.

Kwaliteitseisen voor code in develop

Codekwaliteit in develop moet hoog zijn, maar niet absoluut. In tegenstelling tot main, waar elke fout een spoedige hotfix betekent, staan in develop kleine tekortkomingen toe die vóór de release worden opgelost.

Minimale vereisten voor code vóór samenvoeging in develop:

• Compilatie — code moet zonder fouten compileren. Een gebroken compilatie in develop blokkeert het werk van het hele team.
• Unittests — alle bestaande tests moeten slagen. Nieuwe code moet voor ten minste 70% door tests worden gedekt.
• Code style — code moet voldoen aan de in het team geaccepteerde opmaak- en naamgevingsstandaarden.
• Geen verouderde API's — gebruik van verouderde methoden is niet toegestaan in nieuwe code.

Automatische controles in de CI/CD-pipeline moeten bij elke push naar develop worden gestart. Als de compilatie breekt, moet de verantwoordelijke ontwikkelaar het probleem binnen een uur oplossen of zijn commit terugdraaien.

CI/CD-controles voor develop

Configuratie van GitHub Actions voor develop garandeert dat elke PR vóór samenvoeging een automatische controle doorloopt. Een typische pipeline omvat compilatie, tests en linting.

# GitHub Actions — controleren van develop na samenvoeging
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

Regels voor samenvoegen in develop

Samenvoegen in develop moet strikte regels volgen om de stabiliteit van de integratietak te behouden. Overtreding van deze regels leidt tot conflicten, gebroken compilaties en tijdverlies van het team.

• Alleen via Pull Request — directe push naar develop is verboden. Alle wijzigingen doorlopen code review.
• Minimaal één goedkeuring — een PR moet worden goedgekeurd door ten minste één ontwikkelaar die niet aan de taak heeft deelgenomen.
• Squash merge — het wordt aanbevolen om alle commits van een feature-tak te combineren tot één bij samenvoeging in develop voor een schone geschiedenis.
• Actualiteit van PR — vóór samenvoeging moet de PR worden bijgewerkt ten opzichte van de laatste commit van develop (rebase of merge).

De regel van actualiteit van PR is bijzonder belangrijk. Als een feature-tak een week geleden is gemaakt en develop is 50 commits vooruitgegaan, kan directe samenvoeging leiden tot conflicten die beter in de context van de PR kunnen worden opgelost, niet in develop.

Bescherming van develop tegen onjuiste samenvoegingen

Branch protection rules (takbeschermingsregels) — dit zijn instellingen op GitHub-, GitLab- of Bitbucket-niveau die onjuiste wijzigingen in develop voorkomen. Ze garanderen dat zelfs een accidentele push de integratietak niet zal breken.

Aanbevolen beschermingsregels voor develop:

• Require pull request — verbied directe push naar develop. Alle wijzigingen alleen via PR.
• Require approvals — minimaal 1-2 goedkeuringen vóór samenvoeging van een PR.
• Require status checks — blokkeer samenvoeging als de CI/CD-pipeline niet is geslaagd.
• Require up-to-date — de PR-tak moet worden bijgewerkt ten opzichte van develop vóór samenvoeging.
• Restrict push access — beperk push-rechten naar develop tot alleen senior ontwikkelaars.

Het configureren van develop-bescherming duurt 10 minuten, maar voorkomt weken van stilstand als gevolg van een gebroken integratietak. Voor mobiele projecten met multiplatform-teams is dit bijzonder relevant.

Voorbeelden van commando's voor werken met develop

Laten we een typische dag van een ontwikkelaar bekijken: 's ochtends werkt hij develop bij, maakt een nieuwe feature-tak, en na voltooiing van de taak voegt hij wijzigingen terug naar develop samen.

# Ochtendsynchronisatie van develop
git checkout develop
git pull origin develop

# Nieuwe feature-tak maken van develop
git checkout -b feature/add-push-notifications

# Werken aan functie...
git add . && git commit -m "Add FCM integration"

# Develop bijwerken tijdens ontwikkeling
git fetch origin develop
git rebase origin/develop

# Na goedkeuring van PR — lokale develop bijwerken
git checkout develop
git pull origin develop
git branch -d feature/add-push-notifications

Het commando git pull in develop voert twee bewerkingen tegelijk uit: git fetch (haalt nieuwe commits van de server op) en git merge (voegt ze samen met de lokale tak). Voor develop is dit de standaard manier van synchronisatie.

Herstel van develop na een gebroken samenvoeging

Als er code in develop terecht is gekomen die de compilatie heeft gebroken, moet snel worden gehandeld. Elk uur stilstand van develop betekent geblokkeerd werk van het hele ontwikkelaarsteam.

Als er code in develop terecht is gekomen die de compilatie heeft gebroken, gebruik dan git revert om een nieuwe commit te maken die de problematische wijzigingen ongedaan maakt. Gebruik geen git reset in develop — dit herschrijft de geschiedenis die al bij andere deelnemers bestaat.

# Vinden van problematische commit
git log --oneline develop

# Commit ongedaan maken via revert (veilig)
git revert a1b2c3d

# Correctie naar externe develop sturen
git push origin develop

# Wijzigingen in een specifieke commit bekijken
git show a1b2c3d --stat