Commitment Issues – Git Branching leicht gemacht

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.

Git Branching

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.

Git Branching

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

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.

In case of fire, git commit & git push

by Marco Leong is licensed under CC BY-NC 4.0

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.

Weiterführende Links:

Vincent Driessens Blog mit weiteren Details zum angeführten Modell
Git Cheat Sheet
Git GUI Clients
.gitignore Templates

Die verwendeten Bilder stehen unter der CC BY-NC-SA 3.0 Lizenz und stammen aus dem Buch „Pro Git„.