Develop Branch in Git — was es ist, Zweck und Funktionsprinzipien

Was ist Develop Branch in Git

Develop Branch (Entwicklungsbranch) ist ein langlebiger Branch in Git Flow, der als zentraler Knotenpunkt für die Code-Integration aller Entwickler dient. Feature-Branches werden nach Abschluss der Entwicklung und Code-Review in ihn gemergt.

Code in develop ist immer in einem Zustand, der für die Erstellung eines Releases bereit ist, obwohl er noch nicht in Produktion bereitgestellt wurde. Das bedeutet, dass alle Funktionen in develop Review, Tests und Integrationsprüfungen durchlaufen haben, aber noch auf ihren Release-Zyklus warten.

Im Gegensatz zu main, wo jede Code-Version ein Release ist, enthält develop einen kontinuierlichen Strom von Änderungen. Commits in develop erscheinen, wenn Feature-Branches gemergt werden, was mehrmals täglich geschehen kann.

Laut Vincent Driessen, 2010 ist develop ein Schlüsselelement eines erfolgreichen Branching-Modells, da es Entwurfsarbeit von releasebereiten Versionen trennt.

Unterschiede zwischen develop und main Branch

Die Unterschiede zwischen develop und main zu verstehen, ist für einen korrekten Git Flow-Workflow entscheidend. Diese Branches haben unterschiedliche Funktionen und unterschiedliche Stabilitätsanforderungen.

Die Aufteilung in develop und main ermöglicht es dem Team, kontinuierlich neuen Code zu integrieren, ohne die Stabilität der Produktionsversion zu gefährden. Entwickler können ihren Code in develop sofort nach PR-Genehmigung sehen, noch vor der offiziellen Veröffentlichung.

Rolle von develop in Git Flow

Im Git Flow-Modell nimmt develop eine zentrale Stellung zwischen Feature-Branches (Quelle der Änderungen) und Release-Branches (Vorbereitung für Release) ein. Das Verständnis dieser Hierarchie ist die Grundlage für effektives Branching.

• Feature → Develop — jede abgeschlossene Funktion wird über einen Pull Request mit Code-Review in develop gemergt.
• Develop → Release — wenn genügend Änderungen für ein Release angesammelt sind, wird von develop ein Release-Branch erstellt.
• Release → Main + Develop — nach der endgültigen Vorbereitung wird der Release-Branch in main (Release) und zurück in develop (Bugfixes) gemergt.
• Hotfix → Main + Develop — kritische Korrekturen werden von main erstellt und in beide Branches gemergt.

Diese Struktur stellt sicher, dass develop immer den neuesten Code mit allen neuen Funktionen enthält, während main nur verifizierten Produktionscode enthält. Dies ist besonders wichtig für Mobilprojekte mit langen Review-Zyklen im App Store und Google Play.

Beziehung von develop zu anderen Git Flow-Branches

Develop fungiert als zentrale Verbindung zwischen Feature-, Release- und Hotfix-Branches. Das Verständnis der Merge-Richtungen ist unerlässlich, um Konflikte und Commit-Verluste zu vermeiden.

Code-Qualitätsanforderungen in develop

Die Code-Qualität in develop muss hoch sein, aber nicht absolut. Im Gegensatz zu main, wo jeder Fehler einen dringenden Hotfix bedeutet, erlaubt develop kleinere Unvollkommenheiten, die vor dem Release behoben werden.

Mindestanforderungen an den Code vor dem Merge in develop:

• Kompilierung — Code muss fehlerfrei kompilieren. Ein kaputter Build in develop blockiert die Arbeit des gesamten Teams.
• Unit-Tests — alle vorhandenen Tests müssen bestehen. Neuer Code muss zu mindestens 70% durch Tests abgedeckt sein.
• Code-Stil — Code muss den im Team akzeptierten Formatierungs- und Namensstandards entsprechen.
• Keine veraltete API — die Verwendung veralteter Methoden ist in neuem Code nicht erlaubt.

Automatisierte Prüfungen in der CI/CD-Pipeline sollten bei jedem Push in develop ausgeführt werden. Wenn der Build kaputt geht, muss der verantwortliche Entwickler das Problem innerhalb einer Stunde beheben oder seinen Commit zurücknehmen.

CI/CD-Prüfungen für develop

Die Einrichtung von GitHub Actions für develop stellt sicher, dass jeder PR vor dem Merge automatisierte Prüfungen durchläuft. Eine typische Pipeline umfasst Build, Tests und Linting.

# GitHub Actions — Überprüfung von develop nach dem Merge
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

Merge-Regeln für develop

Der Merge in develop muss strengen Regeln folgen, um die Stabilität des Integrationsbranches zu erhalten. Ein Verstoß gegen diese Regeln führt zu Konflikten, kaputten Builds und Zeitverschwendung des Teams.

• Nur über Pull Request — direkter Push in develop ist verboten. Alle Änderungen durchlaufen ein Code-Review.
• Mindestens eine Genehmigung — PR muss von mindestens einem nicht an der Aufgabe beteiligten Entwickler genehmigt werden.
• Squash Merge — es wird empfohlen, alle Commits des Feature-Branches beim Merge in develop zu einem zusammenzufassen, für eine saubere Historie.
• PR aktuell halten — vor dem Merge muss der PR relativ zum letzten develop-Commit aktualisiert werden (Rebase oder Merge).

Die Regel PR aktuell halten ist besonders wichtig. Wenn ein Feature-Branch vor einer Woche erstellt wurde und develop 50 Commits voraus ist, kann ein direkter Merge zu Konflikten führen, die besser im Kontext des PR als in develop gelöst werden.

Schutz von develop vor fehlerhaften Merges

Branch Protection Rules sind Einstellungen auf GitHub-, GitLab- oder Bitbucket-Ebene, die fehlerhafte Änderungen in develop verhindern. Sie stellen sicher, dass selbst ein versehentlicher Push den Integrationsbranch nicht beschädigt.

Empfohlene Schutzregeln für develop:

• Pull Request erforderlich — direkten Push in develop verbieten. Alle Änderungen nur per PR.
• Genehmigungen erforderlich — mindestens 1-2 Genehmigungen vor dem Merge des PR.
• Statusprüfungen erforderlich — Merge blockieren, wenn CI/CD-Pipeline nicht bestanden wurde.
• Aktualität erforderlich — PR-Branch muss vor dem Merge relativ zu develop aktualisiert werden.
• Push-Zugriff einschränken — Push-Rechte auf develop nur für Senior-Entwickler beschränken.

Die Einrichtung des develop-Schutzes dauert 10 Minuten, verhindert aber wochenlange Ausfallzeiten aufgrund eines kaputten Integrationsbranches. Für Mobilprojekte mit plattformübergreifenden Teams ist dies besonders relevant.

Beispielbefehle für die Arbeit mit develop

Betrachten wir einen typischen Entwicklertag: Am Morgen aktualisiert er develop, erstellt einen neuen Feature-Branch und merged nach Abschluss der Aufgabe die Änderungen zurück in develop.

# Morgendliche develop-Synchronisation
git checkout develop
git pull origin develop

# Erstellen eines neuen Feature-Branches von develop
git checkout -b feature/add-push-notifications

# Arbeiten an der Funktion...
git add . && git commit -m "Add FCM integration"

# Aktualisierung von develop während der Entwicklung
git fetch origin develop
git rebase origin/develop

# Nach PR-Genehmigung — lokales develop aktualisieren
git checkout develop
git pull origin develop
git branch -d feature/add-push-notifications

Der Befehl git pull in develop führt zwei Operationen gleichzeitig aus: git fetch (holt neue Commits vom Server) und git merge (führt sie mit dem lokalen Branch zusammen). Für develop ist dies die Standard-Synchronisationsmethode.

Wiederherstellung von develop nach einem fehlerhaften Merge

Wenn Code, der den Build kaputt macht, in develop gelangt, muss schnell gehandelt werden. Jede Stunde develop-Ausfallzeit ist blockierte Arbeit für das gesamte Entwicklungsteam.

Wenn Code, der den Build kaputt macht, in develop gelangt, verwenden Sie git revert, um einen neuen Commit zu erstellen, der die problematischen Änderungen rückgängig macht. Verwenden Sie git reset nicht in develop — es überschreibt die Historie, die andere Teammitglieder bereits haben.

# Finden des problematischen Commits
git log --oneline develop

# Commit-Rücknahme per Revert (sicher)
git revert a1b2c3d

# Fix an entferntes develop senden
git push origin develop

# Änderungen in einem bestimmten Commit anzeigen
git show a1b2c3d --stat