Best Practice bei der Versionsverwaltung mit Git

Unter Versionsverwaltung verstehen wir ein System, mit welchem Änderungen an Dateien über Zeit nachverfolgt werden können.   Solche Systeme sind aus dem Software Entwicklungsprozess heute nicht mehr wegzudenken. Seit der Entwicklung der ersten Versionsverwaltungssysteme in den 1970er Jahren haben sich Anforderungen und Implementationen von Versionsverwaltungssystemen stark gewandelt.

Mittlerweile hat sich die Versionsverwaltung mit Git   zu einem weit verbreiteten Standard entwickelt. Um als Software-Team Git bestmöglich nutzen zu können, ist es hilfreich, einige Regeln zu definieren. In diesem Blog-Post geht es darum, «Best-Practices» beim Umgang mit Git zu erläutern. Als «Best Practice» werden in diesem Beitrag Vorgehensweisen und Prozesse bezeichnet, die von mehreren Quellen empfohlen werden und sich in der Praxis bewährt haben, beispielsweise in Projekten von M&F Engineering. Diese Praktiken sollten jedoch keinesfalls als gegeben betrachtet werden, sondern als Hilfestellung bei der Ausarbeitung der Team-eigenen Regeln gesehen. Oft sind folgende Kriterien relevant:

1. Entwicklungsprozess – Agil vs. Wasserfall
2. Häufigkeit von Releases / Lebenszyklus der Software
3. Teamgrösse
4. Anzahl Entwickler, die parallel am gleichen Teil der Software arbeiten

Um den Rahmen dieses Beitrags nicht zu sprengen, werde ich darauf verzichten, die grundlegenden Konzepte von Git zu erläutern.

Workflow – Branching & Merging

Visualisierung Branches [iii]  

Mit Workflow wird hier eine Strategie zur Erstellung und Zusammenführung von Branches bezeichnet. In der Praxis werden diverse Workflows angewendet, unter anderen Git Flow, GitHub Flow oder GitLab Flow.  Die Strategien unterscheiden sich vor allem in Anwendungsbereich und Komplexität.

Gemeinsamkeiten haben die meisten Workflows in den folgenden Punkten:

1. Der Master-Branch ist immer stabil
2. Keine Commits direkt in den Master; nur fertig entwickelte Branches werden in den Master gemerged
3. Code-Review sollte bevor dem Merge passieren, idealerweise per Pull-Request   [v]

Commit-Nachrichten

Commit-Nachrichten: HowNotTo   [vi]

Der Wert von präzisen und konsistenten Commit-Nachrichten zeigt sich oft erst dann, wenn ein Projekt eine gewisse Lebensdauer erreicht hat. Besonders für Entwickler, die neu zum Projekt dazustossen, ist das Commit-Log oft die erste Anlaufstelle, um zu verstehen, warum ein Feature auf die eine und nicht auf die andere Weise umgesetzt wurde.

Auch beim Thema Commit-Nachrichten gibt es diverse Ansätze, um langfristig Nachvollziehbarkeit sicherzustellen. Die folgenden 7 Regeln haben sich über viele Projekte hinweg bewährt  :

1. Thema von Textkörper mit Zeilenumbruch separieren
2. Thema auf 50 Zeichen limitieren
3. Thema mit Gross-Kleinschreibung
4. Keine Satzzeichen am Ende vom Thema
5. Im Imperativ schreiben
6. Umbruch nach 72 Zeichen pro Linie für den Textkörper
7. „Was“ und „Warum“ im Textkörper erklären, nicht „Wie“

Zusätzlich ist es oft hilfreich, in der Commit-Nachricht die Ticketnummer oder ähnliches aus dem Projektverwaltungs-Tool (Jira, Azure DevOps etc.) einzubauen. So können auf eine einfache Art zusätzliche Informationen verlinkt werden.

Git Kommandozeile und Clients

Wenn es um die Wahl des bevorzugten Interfaces zum Umgang mit Git geht, landet man bei Diskussionen oft schon fast im philosophischen Bereich. Fakt ist: neben der Kommandozeile existiert eine Vielzahl von grafischen Benutzeroberflächen, welche besonders Git-Neulingen die Arbeit erleichtern kann. Beliebt sind beispielsweise SourceTree, GitHub Desktop oder TortoiseGit. Wer auf zusätzliche Software lieber verzichtet, kann die Git-Oberfläche einer integrierten Entwicklungsumgebung wie etwa Visual Studio Code verwenden.

Wer sich im Umgang mit Git sicher fühlt, für den kann auch die Kommandozeile das richtige Interface darstellen. Im Gegensatz zu allen grafischen Oberflächen ist die Kommandozeile garantiert Plattform-unabhängig, bietet den v

Weitere Ressourcen

https://www.toptal.com/gitflow/enhanced-git-flow-explained