Git-Workflows: Branches, Pull Requests und Rebase

Kurz: Ein Git-Workflow legt fest, wie ein Team Änderungen in ein gemeinsames Projekt bringt. Die meisten arbeiten heute mit kurzen Feature-Branches und Pull Requests.

Grundbegriffe

• Branch: eine eigene Linie von Änderungen. git switch -c feature/login legt einen neuen an.
• Commit: ein gespeicherter Stand mit Beschreibung. Besser mehrere kleine, sinnvoll benannte Commits.
• Pull Request (PR)/Merge Request: Bitte, einen Branch in den Hauptzweig zu übernehmen, samt Prüfung durch andere (Code-Review).

Der übliche Ablauf (GitHub Flow)

1. main ist immer lauffähig.
2. Neuen Branch von main abzweigen.
3. Ändern, testen, committen, pushen.
4. Pull Request öffnen; automatische Tests laufen, andere schauen drüber.
5. Nach Freigabe in main übernehmen, Branch löschen.

Andere Modelle: Git Flow (viele Langzeit-Zweige, für Software mit festen Releases) und Trunk-based (sehr kurze Zweige, ständig zusammenführen, oft mit Feature-Schaltern).

Merge, Squash oder Rebase?

• Merge: verbindet zwei Zweige mit einem Merge-Commit, die Historie bleibt wie sie war.
• Squash: fasst alle Commits des Branches zu einem zusammen, das hält main übersichtlich.
• Rebase: setzt die eigenen Commits auf den neuesten Stand von main, die Historie wird gerade. Goldene Regel: Nie Commits umschreiben, die schon andere haben.

Konflikte

Wenn zwei Leute dieselbe Stelle ändern, markiert Git sie (<<<<<<<). Man entscheidet, behält die richtige Fassung und committet.

Gute Gewohnheiten

Kleine PRs, klare Commit-Nachrichten, Tests vor dem Push, keine Geheimnisse im Repository.

Siehe auch: Git, Test-Driven Development