Auf dem Weg zu einem besseren Git-Workflow

Ich habe Methoden zusammengestellt, um Git effizienter zu nutzen.

0. Repository-Struktur
   • Git ist ein verteiltes Versionsverwaltungssystem, daher sind verschiedene Modelle möglich, etwa zentralisiert, im GitHub-/GitLab-Stil oder hierarchisch
1. Branch-Struktur
   • GitHub Flow: Man hat einen Main-Branch, erstellt Feature- oder Bug-Branches und merged sie nach Feedback
   • Git Flow: Eher für traditionelle Entwicklung geeignet als für häufige Deployments
     • Es werden Feature-Branches erstellt und in den Develop-Branch gemergt
     • Ein ausreichend gereifter Develop-Branch erzeugt einen Release-(Stage-)Branch, an dem nur noch Bugs behoben werden; später wird er wieder in Develop und Master gemergt
     • Wenn das Release bereit ist, wird in den Master-Branch gemergt, danach gibt es nur noch Hotfixes
   • GitLab Flow: Eine Zwischenform zwischen dem komplexen Git Flow und dem zu einfachen GitHub Flow
     • Statt eines im Git Flow nur kurzzeitig existierenden Release-Branches wird ein dauerhaft bestehender Stage-Branch verwendet
     • Hotfixes werden in Production und Stage übernommen, Bugfixes in Stage und Develop
   • Perforce Stream: Vorteilhaft, wenn mehrere Releases verwaltet werden müssen
     • Werden Bugs in Release behoben, werden sie nach Main-Develop weitergegeben
     • Werden Features in Develop erstellt, werden Konflikte beseitigt und dann nach Main übernommen
   • Trunk-basiert: Ein Ansatz, Main (Master) effizienter zu nutzen, der vor allem von Big-Tech-Unternehmen verwendet wird
     • Main wird langfristig beibehalten, im Release-Branch werden keine separaten Bugfixes gemacht
     • Features werden mit Flags im Off-Zustand gemergt, damit der Code stets aktuell bleibt
2. Commits
   • Konventionen: Häufig wird die Angular-Konvention verwendet, per Absprache können aber auch Emojis usw. genutzt werden
   • Granularität: Commits sollten in möglichst kleinen Einheiten erfolgen, aber auch hier braucht es teamintern eine Einigung darüber, was die kleinste Einheit ist
     • Änderungen lassen sich per Hunk weiter aufteilen und stagen
     • Praktisch ist es, wenn sich Änderungen auf Delta-Ebene vergleichen lassen
   • Spekulative Commits und lineare Historie: Eine Methode, häufig zu committen, dabei den Kontext zu bewahren und zugleich die Commit-Historie linear zu halten
     • Immer dann speichern, wenn der Arbeitsstand gesichert werden muss, etwa mit stash oder bei Prototyp-Versuchen
     • Überall dort, wo ein Checkout nötig ist, auschecken und weiter committen; anschließend per rebase die lineare Historie beibehalten
     • Praktisch ist das Tool git-branchless
     • git sl: Verfolgt anonyme Branches und visualisiert die Commit-Historie gut
     • git prev und git next: Erleichtern den Checkout zur vorherigen/nächsten Einheit
     • git sync: Rebase auf Main
     • git move: Erlaubt es, Commits an die gewünschte Stelle zu verschieben
     • git restack: Stellt die Reihenfolge der Commit-Historie wieder her, wenn sie durch rebase oder commit --amend durcheinandergeraten ist
     • git undo: Macht Rückgängig-Aktionen möglich
3. Merge
   • Patch Stack: Eine Review-Methode, bei der in Teile wie Feature[1/3], Feature[2/3], Feature[3/3] zerlegt wird
   • First-Class-Konflikte: Das mit Git kompatible Jujutsu speichert Konflikte in Commits, sodass bereits gelöste Konflikte später seltener erneut auftreten
   • 3-Way-Diff: Bei Jujutsu wird bei Konflikten Base-Ours als Diff und Theirs als Snapshot angezeigt, was intuitiv ist. Allerdings kann es den Bedarf geben, Syntax-Highlighting in IDE/Editor oder einen Base-Theirs-Diff zu sehen
   • Binäre Konflikte: Wenn bei Git Konflikte in Binärdateien auftreten, wird man damit im Grunde allein gelassen; ich habe mir dafür persönlich ein einfaches Tool gebaut, das Base- und Their-Dateien erzeugt
   • Patches und Mail: Einführung in eine traditionellere(?) Art des Mergens
     • git request-pull ist ein Befehl zum Erstellen eines Pull Requests
     • Mit git send-mail lassen sich Patches per Mail versenden, mit git am können sie angewendet werden
4. Weitere Verwaltungsmethoden
   • Worktree: Die Git-Historie bleibt geteilt, während nur die Arbeitsdateien wie bei SVN-Branches an mehreren Orten ausgecheckt werden, sodass mehrere Arbeiten gleichzeitig möglich sind
   • Git LFS: Eine Methode zur Verwaltung großer Dateien
   • Teilweises Klonen und teilweises Auschecken: Durch partielles clone lässt sich die Download-Zeit verringern, und durch partielles checkout kann nur im gewünschten Verzeichnis gearbeitet werden
   • Scalar: Erleichtert durch die Bemühungen von Microsoft die Verwaltung riesiger Repositories