Feature Branch in Git: Was es ist, wie man Branches erstellt und damit arbeitet

Was ist ein Feature Branch in Git

Feature Branch (Funktions-Branch) ist ein temporärer Branch in Git, der von develop erstellt wird, um eine bestimmte Funktionalität zu entwickeln. Im Gegensatz zu den langlebigen Branches main und develop existieren feature-Branches nur für eine begrenzte Zeit — von einigen Stunden bis zu einigen Wochen.

Das Hauptziel eines feature-Branches ist es, Änderungen, die mit einer Aufgabe zusammenhängen, vom restlichen Code zu isolieren. Der Entwickler kann in seinem eigenen Branch experimentieren, viele Commits machen und sogar Code zerstören, ohne die Arbeit anderer Teammitglieder zu beeinträchtigen.

Nach Abschluss der Entwicklung wird der feature-Branch über einen Pull Request mit obligatorischem Code-Review zurück in develop zusammengeführt. Nach der Zusammenführung wird der Branch in der Regel gelöscht, um das Repository sauber zu halten.

Laut Vincent Driessen, 2010 wurde das Git-Flow-Modell mit feature-Branches dank der klaren Aufgabentrennung zwischen verschiedenen Branch-Typen zum Industriestandard.

Workflow mit Feature Branch

Der Workflow mit feature-Branches besteht aus einer Abfolge von Schritten, die der Entwickler für jede neue Funktion ausführt. Dieser Prozess minimiert Merge-Konflikte und gewährleistet die Code-Qualitätskontrolle.

1. Branch erstellen vom letzten Commit von develop. Der Entwickler wechselt zu develop, aktualisiert ihn und erstellt einen neuen feature-Branch.
2. Entwicklung und Commits im feature-Branch. Der Entwickler nimmt Änderungen vor, macht Commits mit klaren Beschreibungen und pusht den Branch regelmäßig in das entfernte Repository.
3. Synchronisation mit develop — während der Entwicklung kann der Hauptbranch voranschreiten. Der Entwickler führt einen Rebase oder Merge von develop in seinen feature-Branch durch.
4. Pull Request erstellen — wenn die Funktion fertig ist, öffnet der Entwickler einen PR zur Code-Review. Das Team überprüft den Code und hinterlässt Kommentare.
5. Zusammenführen und Löschen — nach der PR-Genehmigung wird der Branch in develop zusammengeführt und sowohl lokal als auch remote gelöscht.

Die regelmäßige Synchronisation mit develop ist entscheidend. Je länger ein feature-Branch ohne Zusammenführung von Änderungen aus develop lebt, desto höher ist die Wahrscheinlichkeit von Konflikten bei der endgültigen Zusammenführung.

Synchronisationshäufigkeit des feature-Branches

Namenskonventionen für feature-Branches

Branch-Namensgebung ist ein wichtiger Teil der Team-Disziplin. Ein einheitlicher Namensstandard ermöglicht es, schnell zu erkennen, an welcher Aufgabe gearbeitet wird und wer sie ausführt.

• feature/name — das Präfix feature/ wird im klassischen Git Flow verwendet. Beispiel: feature/added-auth-module.
• feature/JIRA-123-beschreibung — Verknüpfung mit der Aufgaben-Nummer im Tracking-System. Beispiel: feature/PROJ-42-add-login.
• feature/typ/name — erweitertes Format mit Angabe des Aufgabentyps. Beispiel: feature/feat/analytics-dashboard.

Die Verwendung der Aufgaben-ID aus JIRA, Trello oder einem anderen System ist eine bewährte Praxis. Sie verknüpft den Code automatisch mit der Aufgabe und vereinfacht die Branch-Suche über git log.

Pull-Request-Prozess

Pull Request (oder Merge Request in GitLab) ist eine Anfrage zur Zusammenführung des feature-Branches in develop. Ein PR ist nicht nur eine technische Operation, sondern ein teamweiter Code-Review-Prozess, der die Code-Qualität verbessert und Wissen innerhalb des Teams verbreitet.

Ein guter PR enthält einen Titel mit einer kurzen Aufgabenbeschreibung, einen Link zum Ticket und eine Beschreibung der Änderungen. Der Entwickler sollte angeben, was genau gemacht wurde, welche Dateien geändert wurden und ob es potenzielle Risiken für andere Teile des Projekts gibt.

Das Team überprüft den Code im PR, hinterlässt Kommentare, fordert Änderungen an (change requests) und genehmigt die Zusammenführung (approve). Nach der Genehmigung wird ein Merge oder Squash Merge durchgeführt.

Die durchschnittliche PR-Review-Zeit in der mobilen Entwicklung beträgt 4 bis 24 Stunden. Die Bibliothek Danger automatisiert einen Teil der Überprüfungen, indem sie Linter und Tests direkt im PR ausführt.

Empfehlungen für die Erstellung eines guten PR

• Größe — nicht mehr als 300-400 Zeilen Änderungen. Große PRs sind schwer zu überprüfen, die Qualität der Überprüfung sinkt.
• Ein PR — eine Aufgabe — vermeiden Sie das Mischen nicht zusammenhängender Änderungen in einer Anfrage.
• Screenshots — fügen Sie für UI-Änderungen Screenshots vorher und nachher bei.
• Tests — schreiben Sie für neue Funktionalität Unit-Tests und nehmen Sie sie in den PR auf.

Strategien zur Zusammenführung von feature-Branches

Nach der PR-Genehmigung kann der feature-Branch auf verschiedene Weise in develop zusammengeführt werden. Die Wahl der Merge-Strategie beeinflusst die Commit-Historie und die Möglichkeit, Änderungen rückgängig zu machen.

• Merge Commit — erstellt einen Merge-Commit und bewahrt die gesamte Commit-Historie des feature-Branches. Die Historie bleibt vollständig, aber der Verzweigungsgraph wird komplexer.
• Squash Merge — fasst alle Commits des feature-Branches zu einem zusammen und fügt ihn über develop hinzu. Die Historie wird sauberer, aber Informationen über Zwischen-Commits gehen verloren.
• Rebase and Merge — schreibt die Commits des feature-Branches über den letzten develop-Commit und führt ohne zusätzlichen Commit zusammen. Die Historie bleibt linear.

Für mobile Projekte mit häufigen Veröffentlichungen wird am häufigsten Squash Merge verwendet: Er liefert eine saubere Historie in develop, während die Entwicklungsdetails in der PR-Beschreibung und der Tracker-Aufgabe bleiben.

Typische Fehler bei der Arbeit mit Feature Branch

Auch erfahrene Entwickler machen Fehler bei der Arbeit mit feature-Branches. Die Kenntnis typischer Probleme hilft, Zeit- und Datenverlust zu vermeiden.

• Branch lebt zu lange — ein feature-Branch lebt länger als 2-3 Wochen ohne Synchronisation mit develop, was zu massiven Merge-Konflikten führt.
• Commits mit unklaren Beschreibungen — Nachrichten wie „fix“ oder „update“ erklären nicht, was geändert wurde und warum.
• Vermischung von Aufgaben — in einem feature-Branch werden zwei nicht zusammenhängende Funktionen entwickelt, was ein selektives Rückgängigmachen unmöglich macht.
• Fehlende Synchronisation — der Entwickler führt kein git fetch durch und aktualisiert develop nicht, was bei der endgültigen Zusammenführung zu Konflikten führt.

Der beste Weg, diese Probleme zu vermeiden, ist, sich zu Projektbeginn auf Arbeitsregeln zu einigen und automatisierte Überprüfungen in der CI/CD-Pipeline zu verwenden.

Befehlsbeispiele für die Arbeit mit Feature Branch

Betrachten wir ein praktisches Szenario: Ein Entwickler beginnt eine neue Authentifizierungsfunktion in einer mobilen App. Er erstellt einen feature-Branch, arbeitet am Code und schließt die Aufgabe mit einem Pull Request ab.

# Develop aktualisieren und feature-Branch erstellen
git checkout develop
git pull origin develop
git checkout -b feature/add-login-screen

# Arbeit an der Funktion: Commits
git add src/ui/login/
git commit -m "Add login screen layout"

# Feature-Branch auf den Server pushen
git push origin feature/add-login-screen

# Synchronisation mit develop (Rebase)
git fetch origin develop
git rebase origin/develop

# Nach PR-Genehmigung: lokalen develop aktualisieren und Branch löschen
git checkout develop
git pull origin develop
git branch -d feature/add-login-screen

Der Befehl git branch -d löscht den Branch nur, nachdem seine Änderungen vollständig zusammengeführt wurden. Wenn der Branch nicht zusammengeführt ist, schlägt Git die Verwendung von git branch -D zur erzwungenen Löschung vor — verwenden Sie dieses Flag mit Vorsicht.

Automatisierung von Überprüfungen im feature-Branch

Die CI/CD-Pipeline sollte für jeden feature-Branch vor der Erstellung eines PR ausgeführt werden. Dies ermöglicht die Erkennung von Problemen in einem frühen Stadium, bevor der Code zur Überprüfung durch andere Entwickler gelangt.

# GitHub Actions zur Überprüfung des feature-Branches
name: Feature Branch CI

on:
  push:
    branches:
      - 'feature/**'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: ./gradlew test
      - name: Lint check
        run: ./gradlew lint

Die Pipeline überprüft, ob der Code kompiliert, Tests bestanden werden und der Code-Stil den Teamstandards entspricht. Erst nach Bestehen aller Überprüfungen kann ein Pull Request erstellt werden.