Komplex. Ein Adjektiv, das oft mit dem Versionskontrollsystem Git verbunden wird. [1] Und zumindest im Vergleich mit klassischen Versionskontrollsystemen (VCS) wie Subversion hält Git tatsächlich eine steilere Lernkurve bereit. Auf die Frage, wer denn eine „komplexe“ neue Technologie lernen möchte, bleibt es – Überraschung! – meist still.

Wenn es allerdings eine Technologie wäre, die die Qualität der Software und oft sogar die eigene Art, Software zu entwickeln, verbessert? Git ist solch ein Fall, bei dem sich ein wenig Lernaufwand durchaus lohnt. Zudem gibt es mit Desktop-Clients wie Tower [2] für Mac OS oder Tortoise Git [3] für Windows bereits sinnvolle GUI-Tools, die vieles erleichtern.

Installation und Hilfe

Wer Git noch nicht auf dem eigenen Rechner installiert haben sollte, kann dies über die Anleitung im kostenlos verfügbaren E-Book „Pro Git“ (http://progit.org/book/) einfach und schnell nachholen. Dieser Artikel erwähnt die Kommandos nur kurz – ausführliche Infos zu Bedeutung und Parametern gibt es auf der Kommandozeile per „git help <kommando>“ oder online auf gitref.org.

Ein Repository bildet die Grundlage, um in Git arbeiten zu können. Falls für das Projekt noch keines existiert oder man frisch beginnt, kann man mittels „git init“ ein Repository im aktuellen Pfad erstellen. Existiert auf einem Server bereits ein Repository, mit dem man nun lokal arbeiten möchte, kann man dieses per „git clone“ auf den eigenen Rechner holen.

Nachdem man einige neue, gelöschte oder veränderte Dateien vor sich hat, geht es darum, diese Änderungen als Commit im Repository zu verewigen. Im ersten Schritt soll „git status“ anzeigen, welche Änderungen im Working Directory vorliegen. Um bestimmte Änderungen zum nächsten Commit hinzuzufügen, muss man diese explizit in Gits „Staging Area“ vermerken. Hierfür ist das Kommando „git add“ zuständig. In einem konkreten Szenario sieht das wie folgt aus:

Im Abschnitt „Changes to be committed“ listet Git alle Dateien auf, die im nächsten Commit enthalten wären. Diese musste man vorher, wie gesagt, per „git add“ der Staging-Area hinzufügen.

„Changes not staged for commit“ zählt all die Dateien auf, die seit dem letzten Commit zwar Änderungen enthalten, aber noch nicht zur Staging-Area hinzugefügt wurden. Folglich wären sie auch nicht Teil des nächsten Commit, sondern würden einfach als veränderte Dateien im Working-Directory bleiben.

Der letzte Abschnitt listet „Untracked files“ auf. Dies sind Dateien, die noch nicht in der Versionskontrolle und Git somit erst einmal unbekannt sind.

Dieses Szenario enthält eine kleine Besonderheit. Sowohl der Abschnitt der „staged Files“ als auch der Abschnitt der „unstaged Files“ führt die Datei „error.html“ auf. Einige der Änderungen in diesem File werden also im nächsten Commit enthalten sein – andere Teile bleiben als Veränderung bestehen. Dieses Git-Feature erlaubt es, enorm granulare und thematisch saubere Commits zu verfassen. Per „git commit“ speichert man den Commit im lokalen Repository.

Sobald ein Repository einige Commits enthält, lohnt ein Blick in die Historie beziehungsweise in das „Log“ des Projekts. Mit dem Befehl „git log“ erhält man eine Übersicht der letzten Commits.

Der klassische Log-Output zeigt jeden Commit mit seinem SHA1-Hash (das Äquivalent zur Revisionsnummer in klassischen CVCS), dem Autor und Datum des Commits sowie der verwendeten Message. Wer andere Bedürfnisse hat, kann „git log“ beinahe beliebig anpassen. Der Parameter „–oneline“ beispielsweise reduziert die Anzeige auf eine Zeile pro Commit. Mit dem Zusatz „-p“ zeigt man zu jedem Commit den entsprechenden Diff/Patch an, der die konkreten Änderungen in diesem Commit aufführt.

Branching wird zurecht als eines der „Killer-Features“ von Git bezeichnet. Wer den Begriff bereits aus anderen VCS wie Subversion kennt, sollte unvoreingenommen an das Thema herangehen: Branches waren in Git von Anfang an eines der Kern-Features und sind daher extrem einfach und unkompliziert zu verwenden.

Branches erlauben, unterschiedliche Entwicklungsvarianten oder Features in einem Projekt sauber zu trennen. Ein Beispielszenario hilft, dies zu verdeutlichen: Ein Entwickler entscheidet sich, die Entwicklung eines neuen Features zu beginnen. Dazu erstellt er einen neuen Branch, ausgehend vom aktuellen Stand, um die Themen sauber zu trennen: „git branch“ erstellt den neuen Branch und „git checkout“ macht ihn zum momentan aktiven Branch.

Nachdem der Entwickler einige Dinge für das neue Feature implementiert hat, committet er diesen Stand auf diesem Branch (C2 im Schaubild). Der Entwickler hat das neue Features noch nicht fertig gestellt, als ein dringender Bugfix ihn dazu zwingt, wieder am Haupt-Entwicklungszweig (dem Live- oder Produktions-Stand) zu arbeiten. Nachdem er (per „git checkout“) zurück auf seinen master-Branch gewechselt hat, committet der Entwickler den Fix für das Problem (C3). Abermals wechselt er auf den featureX-Branch und committet erneut Änderungen (C4), um die Entwicklung am Feature abzuschließen. Mit einem „Merge“ (C5) führt er dann beide Entwicklungszweige wieder zusammen.

Man stelle sich dieses Szenario einmal ohne Branches vor: Spätestens beim Auftauchen des Bugfixes hätten sich Probleme ergeben. Denn das Projekt enthielt zu diesem Zeitpunkt bereits Code zu einem noch nicht fertigen, also noch nicht release-fähigen Feature.

Bei einem einzigen Feature gestaltet sich das Ganze möglicherweise nicht sonderlich tragisch – in größeren Projekten mit vielen verschiedenen parallelen Features und Entwicklungsstadien werden solche Abläufe ohne Branches allerdings schnell unübersichtlich und fehleranfällig.

Natürlich kennen auch andere VCS das Konzept der Branches. Git allerdings macht Branching so einfach, schnell und mühelos wie kein anderes VCS. Wer Branches in Git erst einmal für sich entdeckt hat, gewöhnt sich schnell daran, ein Dutzend Mal pro Tag den aktiven Branch zu wechseln oder für jeden noch so kleinen Bugfix einen neuen Branch zu erstellen. Eine bessere Übersicht und die saubere Trennung von Code zahlen sich aus.

Begriffe zum Thema Branching

Den momentan aktiven Branch bezeichnet man in Git als HEAD. Den HEAD wechselt man mit dem „git checkout“-Kommando (nicht verwandt mit dem checkout-Befehl aus SVN!). Im entsprechenden Working Directory liegen dann auch die Dateien, die zu diesem Branch (beziehungsweise zum letzten Commit dieses Branches) gehören.

Um den eigenen Code anderen Teamkollegen oder externen Entwicklern zugänglich zu machen, oder umgekehrt, fremden Code in sein lokales Repository zu integrieren, dienen „Remote Repositories“. Mit „git remote add“ kann man beliebig viele Remotes mit seinem lokalen Repository verknüpfen. Um lokale Commits aus seinem aktuellen Branch in ein Remote Repository zu übertragen, nutzt man den Befehl „git push“.

Wenn man hingegen Änderungen von remote in sein lokales Repository integrieren will, steht der Befehl „git fetch“ zur Verfügung. Er lädt Änderungen vom entfernten Server auf den lokalen Rechner herunter – verändert aber noch nichts an den aktuellen Dateien im Working-Directory. Man kann, wenn man die Änderungen per Fetch heruntergeladen und angesehen hat, selbst entscheiden, ob und wann man die Änderungen per „git merge“ in den aktuellen HEAD integrieren möchte. Will man das Herunterladen und Integrieren/Mergen in einem Schritt erledigen, steht „git pull“ als Shortcut zur Verfügung.

Git hat das Potenzial, die Qualität im Software-Entwicklungsprozess zu verbessern. Schnelle Performance durch lokale Operationen, granulare Commits dank der Staging Area und ein einfach zu handhabendes Branching-Konzept sind nur ein paar der Vorteile.

Im nächsten Teil der Artikel-Serie geht es um fortgeschrittene Konzepte sowie einige Tipps und Tricks im Umgang mit Git.