Off-Topic
Commitment Issues - Git Branching leicht gemacht
11. Mai 2017

Git & Git Branching sind aus der Software-Entwicklung nicht mehr wegzudenken. Unzählige Projekte bauen auf die Versionsverwaltung von Linux-Vater Linus Torvalds. Sie ist ein simples, aber mächtiges Werkzeug, mit dem jeder schnell zurecht kommt. Im Team können die Vorstellungen darüber allerdings auseinandergehen. Es folgt ein Guide zum Git Branching - Commitment Issues ade.
Teamwork gepaart mit Source Code
„Ich bin DER Programmierer. Die anderen haben alle keine Ahnung. Mein Code ist Poesie. Meine Programme Gesetz.“
Was wie Gehirnwäsche klingt, soll ein Problem in der Software-Entwicklung aufzeigen: Entwickler arbeiten liebend gern alleine. Wie vereint man nun Code von mehreren Entwicklern? Wie kann man die Kollaboration an Source Code effizient und effektiv ermöglichen? Git ist die Antwort und Git Branching der erlösende Workflow.

Auf Git und dessen Vorteile gehen wir an dieser Stelle nicht ein. Wer mehr dazu erfahren will, liest sich am besten auf der offiziellen Webseite ein: git-scm.com
„Ich bin DER Programmierer. Die anderen haben alle keine Ahnung. Mein Code ist Poesie. Meine Programme Gesetz.“

Git Branching
Ein Branch (dt. Zweig) steht für gewöhnlich für eine bestimmte Entwicklungsphase, die Code-Stabilität oder ein gewisses Feature.
Verwendet man nun Git in einem Projekt, teilt man dieses in solche Zweige auf – Git Branching sozusagen. Vincent Driessen hat in seinem Blog ein hervorragendes Branching-Modell vorgestellt, welches für kleinere Teams noch ein wenig vereinfacht werden kann.
Die Entwicklung wird also in mehrere Zweige unterteilt. Hierzu gehören die beiden Hauptzweige master und develop(ment). Diese Zweige gibt es während der gesamten Entwicklung, während kurzlebige Zweige für einzelne Features, Hotfixes oder Releases normalerweise nur bis zum Merge in den entsprechenden „Eltern-Zweig“ existieren.
master
Dieser Zweig enthält ausschließlich „stable“ Code, also jenen Code, der stabil und funktionstüchtig ist. Aus ihm werden dann Release-Versionen angeboten (z.B. per Tags).
develop(ment)
Hier wird der aktuelle Entwicklungsstand mit Features für das nächste Release abgebildet (z.B. „nightly“ Builds). Sofern der Code stabil ist und alle Tests durchläuft, kann er in den master-Branch rückgeführt (merge) werden.
feature/xyz
Neue Features sollten in eigenständigen feature-Branches entwickelt werden, welche dann zurück in den develop-Branch gemerged werden.
hotfix/xyz
Sofort notwendige Bugfixes kann man in hotfix-Zweigen behandeln und dann in den develop– und master-Branch einpflegen. Theoretisch könnte man Hotfixes auch in develop erstellen, allerdings muss dieser ja nicht zwangsläufig bereit für den Produktivbetrieb sein, weshalb hierfür eigene Branches anzuraten sind.
release/xyz
Zur Vorbereitung neuer Release-Versionen gibt es sogenannte release-Branches. Wie bei Hotfixes erfolgt hier die Rückführung in develop und master.
Fortan mögest du bekannt sein unter dem Namen …
Die Benennung der Branches sollte einer einheitlichen Struktur folgen. Idealerweise ein kurzer, durch Bindestrich getrennter Name, der den Zweig am besten beschreibt. Verwendet man JIRA zur agilen Verwaltung, kann man sogar die Issue/Task-ID einbauen.
Beispiele für solche Branchnamen wären:
-
master
-
develop
-
feature/pdf-creation
-
hotfix/XYZ-43-responsive-layout
-
feature/XYZ-99 -
feature/a-very-long-description-no-really-it-is-not-even-funny
Diese Vorgehensweise erleichtert nicht nur die Zusammenarbeit der Entwickler untereinander, sondern auch die Arbeit des SCRUM-Masters oder Projektleiters, da Branches sofort identifiziert und zugeordnet werden können. Je nach Projekt und Teamgröße empfiehlt es sich natürlich auch, dieses Verfahren mit Pull Requests zu garnieren.
Commit & Push
Projektleiter zum Entwickler: „Wir warten noch immer auf Feature XY! Hast du das nun endlich fertig?“
Entwickler: „Natürlich, das hab ich vor meinem Urlaub im Home Office gemacht!“
Projektleiter sucht im Repository und findet nichts: „Hast du die Änderungen auch gepushed?“
Entwickler: „Hmm, habe ich wohl vergessen.“
So gammelt nun das Feature XY am Heimrechner des Entwicklers herum, während das Projekt darauf angewiesen ist. Committen und Pushen der Änderungen am Source Code/Branch sind also weitere essenzielle Punkte der Kollaboration in der Software-Entwicklung. Diese stellen allen anderen die Änderungen zur Verfügung und sind notfalls reversibel.

Analog zu den Branches sollten Commits auch einem Beschreibungs-Schema folgen, damit sofort ersichtlich ist, was geändert wurde. Die erste Zeile einer Commit-Nachricht sollte deshalb eine kurze Zusammenfassung der Änderungen sein, welche auf eine einheitliche Sprache und vorher festgelegte Schlüsselwörter (z.B. added, removed usw) zurückgreift.
Beispiele für solche Commit-Nachrichten (1. Zeile):
-
fixed slider pagination
-
XYZ-56 added initial printing feature
-
XYZ-57 XYZ-58 changed colour scheme, removed log files
-
fix -
XYZ-59
Natürlich braucht die Umstellung des Workflows eine gewisse Einarbeitungszeit, aber dafür wird man als Team mit einer konsistenten Struktur belohnt und ermöglicht die Zusammenarbeit, ohne das Repository in ein Tohuwabohu zu verwandeln.