Git to Go
Git to Go
Buy on Leanpub

1. Einleitung

Git ist der de facto Standard für die Versionsverwaltung von Quellcode geworden. Das Distributed Version Control System (DVCS) hat sich durchgesetzt gegen den vorherigen de facto Standard einer zentralen Versionsverwaltung - Subversion - und den DVCS-Wettbewerber Mercurial.

An dieser Entwicklung war sicherlich maßgeblich beteiligt GitHub als Hoster für Git, der es jedem leicht gemacht hat, ein Repository aufzusetzen. Bitbucket hatte demgegenüber auf Mercurial gewettet und erst später mit Git nachgezogen.

Beide bieten heute kostenlose öffentliche Repositories an, Bitbucket sogar kostenlose private für bis zu 5 Benutzer. Einer Nutzung von Git auch für kleinste Projekte steht damit nichts im Weg.

Teams können co-located sein oder verteilt. Es kann on-premise Infrastruktur zur Speicherung von Repositories benutzt werden oder die von Anbietern wie GitHub oder Bitbucket in der Cloud. Auch nur eine Zeile Code ohne Absicherung durch eine Versionsverwaltung zu schreiben, wäre töricht.

Doch wie funktioniert Git? Ist die Benutzung einer auch noch verteilten Versionsverwaltung nicht ein lästiger Overhead? Ist Git nicht ein Hacker-Tool mit komplizierten Kommandozeilenbefehlen?

Tatsächlich hat Git lange Zeit nicht viel getan, um sich in die Herzen der Massen zu spielen. Installation und Bedienung waren vergleichsweise kompliziert. Wer z.B. Subversion mit dem Tortoise-Client unter Windows gewohnt war, sah sich einer steilen Lernkurve gegenüber.

Doch das ist nun schon lange anders. Es gibt für Windows und Max OSX leistungsfähig und bequeme Git-Clients mit graphischer Benutzeroberfläche. Dem “Hacker-Profi” mögen sie nicht genügen; der lässt nichts auf die maximal flexible Bedienung von Git via Kommandozeile kommen. Doch die Mehrheit der Softwareentwickler, d.h. Sie und ich, bekommt mit diesen Clients alles, was sie im täglichen Umgang mit Quellcode braucht.

Auch Git-Einführungen gibt es inzwischen reichlich (s. Literaturhinweise). Allerdings beziehen die sich vor allem auf die Bedienung von Git via Kommandozeile. Das ist für fortgeschrittene Anwender und Spezialfälle hilfreich - doch einem ersten Einstieg und für schnelle Erfolge, die zur weiteren Beschäftigung mit Git motivieren, ist das nicht dienlich.

Deshalb dieses Büchlein. Mit ihm möchte ich die Einstiegshürde für Neugierige und Zögerliche senken.

Git ist nicht mehr im Kommen. Git ist schon hier. Und Git wird noch einige Jahre bleiben. Dafür wird schon zuviel (Open Source) Software in Git-Repositories verwaltet. Die Integration von Git in Entwicklungswerkzeuge wie Visual Studio, Xamarin Studio oder IntelliJ nimmt zu und wird besser: selbst Microsofts Team Foundation Server (TFS) steht sich mit Git gut. Im Grunde können Sie also schon heute Git nicht mehr ausweichen - und warum auch? Sein Paradigma der verteilten Versionsverwaltung bietet mehr Entkopplung und Flexibilität als eine zentrale Versionsverwaltung. Und obendrein kostet Git nichts.

Deshalb: Nehmen Sie sich ein wenig Zeit und probieren Sie Git einmal mit einem graphischen Client aus. Im Folgenden stelle ich den GitHub Client vor. Alternativ können Sie aber auch z.B. SourceTree oder SmartGit oder Gitbox verwenden.

Derzeit am einfachsten erscheint mir jedoch der GitHub Client. Also, auf zur Installation…

2. GitHub Git-Client installieren

Die Installation des GitHub Client ist denkbar einfach unter Windows wie OSX. Die aktuellen Download-URLs finden Sie bei Google:

Die Download-Seiten lassen keinen Zweifel, wie schnell es geht. Sie sind auf das Wesentliche reduziert.

Auch daran zeigt sich, dass Git für die Massen bereit ist. Wo andere Werkzeuge noch umständliche Download-, Installations- oder gar Übersetzungshinweise in plattformspezifischer Ausprägung anbieten, da kommt der GitHub Client mit Doppelklick-Installation.

Unter Windows werden auch gleichzeitig die Kommandozeilenwerkzeuge mit installiert. Bei OSX hingegen ist nach der Installation noch ein kleiner weiterer Schritt nötig: In den Einstellungen müssen Sie die Kommandozeilenwerkzeuge explizit nachinstallieren.

Aber keine Bange, eigentlich sollten Sie diese Kommandozeilenwerkzeuge ja gar nicht brauchen.

Das war’s, was die Installation des GitHub Client angeht. Der Vorgang ist ansonsten selbsterklärend, denke ich. Sie sind ja Profi, was den Umgang mit Setups auf Ihrem Betriebssystem angeht ;-)

3. Alleine arbeiten

Der Nutzen von Git entfaltet sich natürlich vor allem bei der Arbeit im Team. Erste Gehversuche können Sie aber auch allein machen. Und auch danach ist Git hilfreich, wenn Sie nur für sich an Code arbeiten. Kein Experiment, keine Code Kata mehr ohne ein Repository. Es ist zu einfach, eines aufzusetzen, als dass es zukünftig noch eine Ausrede für Sie gäbe, ohne dieses Sicherheisnetz zu arbeiten ;-)

3.1 Persönliches Repository anlegen

Wenn Sie den Git Client starten, bietet er Ihnen eine Übersicht Ihrer Respositories.

Die ist unterteilt GitHub-Repositories und andere. Der GitHub Client macht es Ihnen leicht, Repositories auf GitHub anzulegen und von dort zu klonen (d.h. “herunterzuladen”). Aber wenn Sie ein Git-Repository schon geklont haben, dann ist dem Client “die Quelle” einerlei und Sie können ihn darauf ansetzen.

Im Moment haben Sie jedoch wahrscheinlich noch kein Repository. Sie beginnen ja erst die Nutzung von Git. Deshalb zeige ich Ihnen als erstes, wie Sie sich ein persönliches anlegen: Klicken Sie auf das + über der Repository-Liste. Wählen Sie dann Create und geben Sie einen Namen für Ihr Repository ein:

Außerdem wählen Sie ein Verzeichnis, in dem Sie es lokal erzeugen. Das kann auf Ihrem Rechner oder einem Fileserver im lokalen Netzwerk sein.

Für Git ist keine Installation einer Serversoftware nötig. Alle Operationen auf Git-Repositories nehmen Git Clients vor.

Das Ergebnis ist ein neuer Eintrag in der Rubrik “OTHER”. Das Repository existiert ja nur lokal. Es hat keine Verbindung zu einem GitHub-Repository.

Auf der Festplatte hat der Client ein Verzeichnis angelegt und mit einem unsichtbaren .git-Verzeichnis versehen.

Das .git-Verzeichnis ist für Sie tabu. Deshalb ist es normalerweise unsichtbar. Dort werden Ihre Änderungen protokolliert, wenn Sie sie committen (“aufzeichnen”).

Der Rest des Repository-Verzeichnis ist Ihr Arbeitsbereich. Dort erzeugen, ändern, löschen Sie Dateien und Verzeichnisse.

3.2 Änderungen aufzeichnen

Im vorangehenden Bild sehen Sie schon, dass ich eine Datei im Arbeitsbereich angelegt habe: herbstgedicht.txt.

Wenn ich diese Änderung im Repository aufzeichnen möchte, dann muss ich sie committen. Im Client gehe ich dazu auf den Reiter “Changes”:

Dort zeigt Git alle Änderungen an Dateien in einer Liste an. Es wird zwischen geändert, gelöscht und hinzugefügt unterschieden.

Standardmäßig sollen natürlich alle Änderungen aufgezeichnet werden. Deshalb ist “Select All” angehakt. Sie können aber auch selektiv committen, falls Sie einige Änderungen noch nicht für “reif” halten.

Rechts zeigt der Client Ihnen noch pro Datei, was sich gegenüber der vorherigen Version verändert hat. Hier ist alles grün unterlegt, d.h. der komplette Dateiinhalt ist neu.

Wenn ich nun der Aufzeichnung einen Titel gebe oder gar noch eine erläuternde Beschreibung, dann kann ich sie committen.

Sie wandert dann in die Liste der unsynchronisierten Commits:

Das sind die Commits, die noch nicht zu einem “Mutter-Repository” übertragen wurden, von dem dieses geklont wurde. Solange Sie allein auf einem persönlichen Repository arbeiten, wird sich daran auch nichts ändern. Lassen Sie sich dadurch nicht verwirren. Die Änderungen sind aufgezeichnet; ich kann jederzeit dahin zurückkehren. Das Sicherheitsnetz ist gespannt.1

Die Historie der Änderungen (oder das Logbuch) zeigt Ihnen jederzeit, welche Aufzeichnungen Sie vorgenommen haben. Zu jeder darin eingeschlossenen Datei können Sie sehen, was daran verändert wurde.

Als nächstes keine neue Datei, sondern die vorhandene Datei verändern. Sie sehen, ich habe den Text etwas korrigiert und ergänzt:

Auch wenn ich aus meiner Sicht, die bisherige Zeile verändert habe, nimmt Git jedoch an, sie sei gelöscht und durch eine neue ersetzt worden. Aber das macht ja nichts.

Mit einer Commit-Nachricht versehen, zeichne ich das auf. Es wächst das Logbuch:

Schließlich noch die Aufzeichnung einer Löschung. Oder genauer: Ich habe die Datei umbenannt und Git nimmt das wahr als Löschung einer Datei und Hinzufügung einer neuen.

In jedem Fall müssen Sie nichts unternehmen, um Löschungen oder Umbenennungen speziell bekannt zu geben. Git beobachtet das Arbeitsverzeichnis “und zieht seine Schlüsse”. Sie zeichnen einfach nur die Veränderungen auf.

Und so geht es immer munter weiter. Ändern, aufzeichnen, ändern, aufzeichnen… Scheuen Sie sich nicht, das ganz kleinschrittig zu tun. Umso präziser können Sie frühere Datei- und Verzeichnisstände wieder herstellen.

Fortgeschrittene können viele kleine Commits auch zu einem großen zusammenfassen, um die Übersichtlichkeit des Logbuchs zu erhöhen (s. dazu den Anhang “Änderungen zusammenfassen”).

4. Im Team arbeiten

Git ist für die Teamarbeit gemacht.

Während bei zentralen Versionsverwaltungssystemen wie Subversion alle Teammitglieder ständig Zugriff auf einen Server haben müssen, sind sie mit Git als DVCS frei, sich unabhängig zu bewegen. Es gibt keinen Server mehr, der die eine Repository-Wahrheit enthält. Repositories sind vielmehr immer lokal bei jedem Entwickler - allerdings können sie von einem “Mutterrepository” “abstammen” und bleiben dann mit ihm verbunden.

4.1 Team-Repository anlegen

Teamarbeit mit Git beginnt damit, ein “Mutterrepository” aufzusetzen. Das können Sie mit dem GitHub Client ganz leicht in der Cloud bei GitHub tun (s.u. das Kapitel “Online arbeiten”). Dann ist der Zugriff von überall her möglich, solange Internetzugang existiert.

Oder Sie können ein “Mutterrepository” im lokalen Netz “von Hand” anlegen. Mit dem GitHub Client ist das leider nicht möglich.

Ein “Mutterrepository” (oder auch bare repository) ist insofern speziell, als dass es keinen Arbeitsbereich für Sie enthält. Es besteht nur aus dem, was bisher im .git-Verzeichnis lag.

Ein solches “Mutterrepository” wird später von den Teammitgliedern geklont. Sie erzeugen sich also eigene “Abzüge” davon, in denen sie lokal Änderungen aufzeichnen. Erst durch eine explizite Synchronisierung wandern die ins “Mutterrepository” und können von dort an andere Teammitglieder verteilt werden, wenn die sich mit ihm synchronisieren.

Git unterscheidet hier Push und Pull Operationen; der GitHub Client jedoch verbirgt dies hinter dem Begriff “Synchronisierung” (s.u.).

Unter Teamarbeit verstehe ich übrigens jede Arbeit an einem Repository mit mehreren Klonen. Auch wenn Sie allein sind, kann das nötig sein, z.B. wenn Sie auf dasselbe Repository von verschiedenen physischen oder virtuellen Rechnern zugreifen. Ich arbeite z.B. oft an Projekten sowohl mit Mac OSX wie mit Windows (in einer virtuellen Maschine unter OSX).

Ein bare repository erzeugen

Am Anfang der Teamarbeit auf einem Rechner oder im lokalen Netz steht die Einrichtung eines bare repository, also eine expliziten “Mutterrepository”.

Dazu legen Sie ein von allen Teammitgliedern erreichbares Verzeichnis an und rufen darin Git von der Kommandozeile mit diesem Befehl auf:

1 git init --bare

Git füllt daraufhin das Verzeichnis seinen Datenstrukturen wie im Bild gezeigt:

Die Konvention ist, solche “Mutterrepositories” mit dem Suffix .git zu versehen.

Ein Repository klonen

Auf dem “Mutterrepository” können Sie nicht direkt arbeiten. Sie müssen es klonen. Das ist wiederum mit dem Kommandozeilenwerkzeug möglich.

Gehen Sie in das Verzeichnis, in dem Sie den Klon erzeugen wollen und rufen Sie Git z.B. so auf:2

Im Beispiel lege ich “Mutterrepository” und Klon im selben Elternverzeichnis Projects ab. Deshalb fehlt ein Pfad vor der Angabe des “Mutterrepository”-Namens.

Anschließend finden Sie ein neues Verzeichnis mit allen Daten des “Mutterrepository” bei sich vor. Darauf können Sie den GitHub Client ansetzen. Darin können Sie Veränderungen vornehmen. Es enthält ein .git-Verzeichnis und ist ansonsten Arbeitsbereich.

Sie fügen diesen Klon über “Add” der Liste von Repositories im Client hinzu:

Oder sie ziehen das Verzeichnis aus dem Finder/Explorer in den “OTHER”-Bereich der Übersicht.

Ein lokales “Mutterrepository” wie das oben angelegte, lässt sich mit dem GitHub Client leider nicht in einem Schritt klonen. Einfacher ist das bei online GitHub Repositories.

4.2 Änderungen synchronisieren

Änderungen zeichnen Sie auf dem Klon wie gewohnt auf. Es ist Ihr persönliches Arbeitsrepository.

Als Beispiel habe ich wieder eine Datei mit Herbstgedicht hinzugefügt.

Anschließend jedoch synchronisieren Sie den Klon mit dem “Mutterrepository”. Das geschieht über “Publish” rechts im Fenster des GitHub Client:

Der Client zieht sich dann zuerst alle neuen Aufzeichnungen vom “Mutterrepository” (pull) und veröffentlicht anschließend Ihre neuen Aufzeichnungen (push).

Synchronisierung ist nur möglich, wenn keine Änderungen in Ihrem Klon unaufgezeichnet sind!

Unter “Branches” sehen Sie nun, dass Ihr Arbeitsbereich (genauer: Ihr Ast in Ihrem Klon) veröffentlicht ist:

So einfach kann die Arbeit im Team mit Git sein. Wer an einem Repository mitarbeiten will, klont es. Dann zeichnet er Änderungen im Klon auf. Schließlich veröffentlicht er sie im “Mutterrepository” - gleichzeitig bekommt er die Aufzeichnungen der anderen mitgeteilt.

Das funktioniert, solange man sich nicht auf die Füße tritt…

4.3 Konflikte auflösen

Um zu demonstrieren, was Sie tun können, wenn es zu Konflikten beim Synchronisieren kommt, lege ich einen zweiten Klon des “Mutterrepository” an. Die Prozedur mit dem Kommandozeilenwerkzeug kennen Sie ja schon:

In diesen Klon lege ich eine weitere kleine Datei mit einem Gedicht:

Jetzt enthält dieser Klon eine neue Datei und die Datei, die ich im ersten hinzugefügt und synchronisiert habe:

So weit so unspannend. In den geklonten Repositories wird unabhängig an Dateien gearbeitet.

Doch jetzt kommt es zum Konflikt. Im neuen Klon wird am Herbstgedicht eine Veränderung vorgenommen und aufgezeichnet und synchronisiert:

Im ersten Klon ebenfalls:

Dadurch schlägt die Synchronisierung fehlt!

In der Pull-Phase bemerkt Git, dass lokal wie im “Mutterrepository” an herbst.txt etwas verändert wurde. Die Synchronisierung wird daher abgebrochen.

Der Git-Client schlägt nun automatisch einen neuen Commit vor, in dem die konfligierenden Dateien gelistet sind. Sie haben jetzt die Gelegenheit, die Konflikte aufzulösen.

Mit einem Doppelklick auf der Datei, wo Änderungen im Konflikt stehen, kann ich sie einsehen und manuell die Konflikte auflösen. Git hat sie in Spitze klammern eingeschlossen. Die Gleichheitszeichen trennen die Änderungen hüben von denen drüben.

Ich entscheide mich für eine Mischung der Änderungen und committe.

Nach beiderseitigen Synchronisation sind beide Repository-Klone auf dem selben Stand. Eintracht ist hergestellt.

In diesem Fall habe ich die Konflikte in einem normalen Texteditor behoben. Es geht jedoch auch komfortabler. Hier eine Impression von der Arbeit mit SourceTree:

Sie sehen im speziellen Merge-Editor, wie die im Widerstreit stehenden Änderungen gegenübergestellt sind. Dort kann ich mich leicht für die links oder rechte Variante entscheiden.

Aber nicht nur zwei Änderungen in einer Datei können zu Konflikten führen. Es kann auch das eine Teammitglied den Inhalt ändern und das andere die Datei löschen.

Hier wird in einem Repository-Klon in die eine Richtung gezogen:

Und im anderen in eine andere:

Das führt bei der Synchronisation zu einem Konflikt:

Ich entscheide mich dafür, die Datei zu behalten. Git hat sie mir gelassen, obwohl sie im anderen Repository-Klon schon gelöscht und synchronisiert war. Also muss ich einfach nur nochmal mit Commit “bestätigen” und auf beiden Seiten synchronisieren:

Sie sehen: Keine Angst vor Konflikten! Solange Konflikte entstehen in Dateien, wo Sie überschauen können, wie sie aufzulösen sind, ist die Kollision kein Drama.

In üblichen Quellcodedateien ist das der Fall. In Dateien jedoch, die eigentlich von einem Tool gepflegt werden wie Projektdateien, die eine IDE verwaltet, kann es schwierig werden. Etwas Obacht ist also bei der Teamarbeit angezeigt. Es ist halt wie im richtigen Leben, wo etwas Rücksicht auf einander es allen leichter macht.

4.4 Änderungen isolieren

Solange Sie allein arbeiten, haben Sie alles unter Kontrolle. Die Codebasis verändert sich in Ihrem vollen Bewusstsein. Je größer das Team desto eher passieren jedoch Dinge, die Sie überraschen könnten, d.h. in Ihrer Konzentration stören würden. Sie haben kein Fundament mehr, auf dem Sie verlässlich aufsetzen können.

Und umgekehrt verändern Sie die Codebasis potenziell in einer Weise, die vorläufig für andere Teammitglieder hinderlich sein kann.

Die Situation bessert sich, wenn unterschiedliche “Projekte” in einem Repository entkoppelt vorangetrieben werden können. Jedes “Projekt” sieht dann nur seine Änderungen; niemand grätscht ihm in seine Idee vom Voranschreiten hinein. Zu diesem Zweck gibt es Repository-Äste (branches).

In Ästen finden Aufzeichnungen isoliert statt - bis sie in andere Äste hineingemischt (to merge) werden.

Branching und merging sind mit Git sehr einfach. Sie “kosten nichts”; dafür werden Repository-Inhalte nicht vervielfacht.

Normalerweise arbeiten alle Teammitglieder auf dem master branch. Davon können Sie jedoch jederzeit abweichen:

Branch anlegen

Wenn Sie sich entscheiden, z.B. ein Feature auf einem eigenen Ast zu entwickeln (feature branch), dann legen Sie dafür kurzerhand einen Branch an:

Von nun an, finden alle Aufzeichnungen auf dem neuen Ast statt. Der existiert zunächst nur in Ihrem Repository-Klon.

Wenn Sie wollen, können Sie ihn jedoch publizieren und anderen Teammitgliedern zugänglich machen. Alle Äste sind gleichberechtigt. Aufzeichnungen in ihnen laufen parallel und unabhängig. Sie haben das Gefühl, ihr eigenes Repository zu haben.

Andere Klone bekommen zwar Ihren Ast ebenfalls zugespielt bei der Synchronisierung, doch sie müssen sich nicht darauf einlassen. Jeder arbeitet auf dem für sich interessanten Ast:

Unter dem Namen Git Flow hat sich inzwischen sogar Muster im Umgang mit Branches herausgebildet.3 Sie können ja mal schauen, ob Sie sich darauf einlassen wollen. Vielleicht gehört Ihr Team ja auch noch zu denen, die sich nicht recht trauen, offensiv mit Ästen umzugehen, weil… ja, warum eigentlich? Weil es mit anderen VCS “teuer” war? Weil Sie merge-Konflikte scheuen? In jedem Fall sollten Sie dem Thema branching mit Git nochmal eine neue Chance geben. Sie werden feststellen, dass der Umgang mit branches in Git leichtgewichtiger ist.

4.5 In Branches aufzeichnen

Zur Demonstration der Unabhängigkeit der Branches lege ich nun Änderungen in zweien in verschiedenen Klonen an.

Hier der Zustand vor der Veränderung. Der Arbeitsbereich, der auf den neuen Branch geschaltet ist:

Und der Arbeitsbereich im anderen Klon, der auf den master geschaltet ist:

Im neuen Branch füge ich dem Herbstgedicht eine Strophe hinzu:

Im master erweitere ich das Wolkengedicht von Hesse:

Leider bietet der GitHub Client keine schöne Übersicht über die Entwicklung der Aufzeichnungen in den verschiedenen Ästen. Aber SourceTree hilft. So sieht es nach dem Synchronisieren beider Klone aus:

Das ist der Blick auf den Repository-Klon, bei dem der neue Ast im Fokus ist. Aber die Entwicklung auf dem master branch ist ebenfalls zu sehen. Beide haben einen unabhängigen Kopf.

Dass es auch in der Vergangenheit des Repository Äste gegeben zu haben scheint, ist den Konflikten geschuldet. Da hatte ja auch getrennte Entwicklung in zwei Klonen stattgefunden - die dann nicht überein gebracht werden konnte. Auch wenn in beiden Klonen auf dem master branch gearbeitet wurde, hat Git das im Grunde als Aufzeichnungen auf verschiedenen Ästen angesehen, die zusammengeführt werden mussten. Meist klappt das problemlos, so dass hinterher nur ein Ast sichtbar bleibt. Doch im Konfliktfall gibt es eben solche kurzzeitigen Verästelungen.

Doch jetzt ist alles anders. Jetzt ist der Ast explizit gewollt. Die Aufzeichnungen darauf sollen nicht mit denen auf dem master jederzeit automatisch zusammengemischt werden.

4.6 Branches zusammenführen

Explizite Äste werden nur auf Ihren Wunsch zusammengeführt. Und Sie bestimmen, von wo nach wo die Aufzeichnungen eingemischt werden.

Hier entscheide ich mich, dass die Aufzeichnungen aus dem neuen Branch in den master branch fließen sollen:

Der GitHub Client macht das sehr einfach. Mit Drag&Drop ziehe Quell-Ast und Ziel-Ast in die dafür vorgesehenen Käste rechts oben im Bild. Dann klicke ich “Merge Branches”. Fertig.

Es wird eine neue Aufzeichnung “Merge branch …” angelegt. Damit sind die bisher isolierten Änderungen im expliziten Branch in den master branch übernommen:

Nun kann ich wieder synchronisieren und alle Teammitglieder sehen, was ich in meinem feature branch getan habe, auch wenn sie bisher auf dem master gearbeitet haben.

SourceTree macht es wieder besonders deutlich, was da passiert ist. Sie sehen, beide Äste sind nun wieder im master zusammengeführt:

Der explizite Ast existiert jedoch weiter. Ich kann ihn belassen oder löschen oder ich kann umgekehrt die zwischenzeitlichen Änderungen am master auch in ihn einmischen, falls ich dort isoliert weiterarbeiten möchte.

5. Online arbeiten

Bisher haben Sie allein oder schon im Team mit offline Repositories gearbeitet. Das können Sie jederzeit, auch im Zug in einem Tunnel oder im Stau ;-) Wie gesagt: Keine Aufgabe sollte ab heute zu klein sein, dass Sie sie nicht mit einem Git Repository absichern.

Noch flexibler werden Sie in puncto Arbeitsort und -zeit natürlich, wenn Sie Ihre Repositories online ablegen. Es gibt viele Hoster, die das kostenlos oder kostengünstig ermöglichen. GitHub und Bitbucket sind nur die bekanntesten.

Verständlicherweise macht der GitHub Client es am einfachsten, mit online Repositories bei GitHub zu arbeiten. Sie können ein persönliches, lokal erzeugtes Repository jederzeit über “Publish” dort anlegen.

Oder Sie beginnen umgekehrt bei GitHub und legen dort ein Repository an. Sie haben dann noch weitere Einstellungsmöglichkeiten:

Allen voran können Sie das Repository von vornherein mit einer “Eröffnungsseite” versehen, die Ihr Projekt beschreibt, und ihm eine .gitignore-Datei mitgeben, die dafür sorgt, dass bestimmte Dateien vom Arbeitsbereich nicht ins Repository wandern. Das ist vorteilhaft für temporäre Dateien oder binäre Artefakte. GitHub bietet hier schon sprach-/plattformspezifische Musterlösungen.

Wenn Sie online in Ihrem Konto ein Repository eingerichtet haben, dann tragen Sie Ihr Konto auch im GitHub Client in den Einstellungen ein:

Anschließend finden Sie Ihre online Repositories zum Klonen angeboten:

Wenn Sie eines auswählen, können Sie bestimmen, wohin es auf Ihrem Rechner geklont werden soll:

Wie Sie sehen, wird daraus wieder ein persönliches Repository mit einem .git-Verzeichnis.

Nun können Sie mit Veränderungen und Aufzeichnungen und Synchronisierungen starten. Als Beispiel eine neue Datei:

Die sich nach einer Synchronisierung auch online findet:

Das online Repository entspricht dem bisherigen bare Repository. Nur liegt es nicht mehr bei Ihnen lokal, sondern bei GitHub - und bietet dort auch noch eine Menge mehr Werkzeuge wie Issue Tracking oder Wiki.

Vergleichen Sie in dieser Hinsicht auch die Hoster von Git Repositories. Schon GitHub und Bitbucket unterscheiden sich hier in z.T. wesentlichen Punkten. Allemal die Möglichkeit, private Repositories bei Bitbucket anzulegen, ist es mir immer wieder wert, auf etwas Bequemlichkeit beim Anlegen von Repositories zu verzichten.

Da werfe ich gern für den ersten Schritt SourceTree als Client an, bis ich ein neues online Repository bei Bitbucket erzeugt und auf meinen Rechner geklont habe. Dann wechsle ich zum GitHub Client für größere Einfachheit.

Schauen Sie, welcher Anbieter- und Tool-Mix Ihnen am besten taugt.

6. Literatur

  • Die Git-eigene Dokumentation - hier finden Sie die ganze Wahrheit ;-)
  • Atlassian, Git Tutorial - ebenfalls eine Einführung in die Kommandozeilentools, doch locker zu lesen und bildreich
  • Scott Chacon, Pro Git - ein ganzes Buch zu Git, online & kostenlos
  • Roger Dudler, git - the simple guide - lockere und knappe Einführung in den Umgang mit Git auf der Kommandozeile
  • Vincent Driessen, A successful Git branching model - Beschreibung von Git Flow
  • Joel Spolsky, Hg Init: a Mercurial tutorial - hier gehts zwar um den Wettbewerber Mercurial, dennoch finde ich das Tutorial ganz hilfreich, wenn man mehr über das Prinzip verteilter Versionskontrolle lernen möchte. Aber Achtung: auch hier wieder ein Kommandozeilenwerkzeug im Einsatz.

7. Anhang: Aufzeichnungen zusammenfassen

Was tun, wenn Sie wirklich sehr kleinschrittig Ihre Änderungen aufgezeichnet haben und am Ende einer Implementationsphase denken, soviel Detail ist eigentlich gar nicht mehr nötig? Dann können Sie Aufzeichnungen zusammenfassen.

Die Git-Dokumentation beschreibt ausführlich, wie das geht - allerdings bezogen auf die Kommandozeilenwerkzeuge.

Wenn Sie es visueller haben wollen, dann können Sie denselben Effekt zum Glück jedoch auch z.B. mit dem kostenlosen SourceTree-Client erzielen.

Hier sehen Sie ein Repository mit drei Commits:

Zwei davon hängen so eng zusammen - “Advent begonnen”und “Weitere Strophen” -, dass ich sie zusammenfassen möchte, bevor ich sie synchronisieren.

Dazu rufe ich über das Kontextmenü auf dem vorhergehenden Commit “Rebase children” auf. Dann werden mir die beiden in Frage stehenden Aufzeichnungen in einem neuen Dialog angeboten:

Dort wähle ich auf dem letzten, den ich mit vorhergehenden zusammenfassen möchte, im Kontextmenü “Squash with previous”.

Das Resultat ist ein neuer Commit-Vorschlag, der die beiden früheren umfasst:

Seine Beschreibung kann ich nun anpassen…

…und dann endgültig aufzeichnen:

Die Geschichte wurde umgeschrieben. Der frühere Verlauf der Aufzeichnungen ist durch eine einzige neue ersetzt worden.

Keine Angst also vor einer unüberschaubaren Zahl von Aufzeichnungen. Committen Sie oft, committen Sie kleinschrittig. Das Logbuch dient Ihnen dann als schöne Übersicht Ihres Weges bei der Realisierung von Veränderungen. Sie brauchen keine Angst haben, etwas zu verlieren, weil Sie beim Zurückrollen im Falle einer Sackgasse, mehr als nötig wegwerfen.

Und wenn Ihnen am Ende die vielen kleinen Schritte ohne Interesse für die Zukunft oder andere Teammitglieder erscheinen, dann fassen Sie sie geschwind zusammen.

Sehen Sie kleinschrittige Commits “unterwegs” wie eine Gerüst um einen Rohbau an. Das hat solange Sinn, wie noch gebaut wird. Ist der Bau fertig, nimmt man es ab. Ebenso stützen Sie beim “Feature-Bau” viele Commits - und verschwinden, wenn sie ihren Zweck erfüllt haben.

  1. Vorsicht jedoch beim Zurückrollen! Das geht ganz einfach, indem sie auf ein Commit doppelklicken. Doch dann gehen seitdem vorgenommene Änderungen verloren - sofern sie nicht schon in ein “Mutter-Repository” übertragen wurden.
  2. Beachten Sie, dass Git die Extensions .git verschluckt hat. Sie kennzeichnet ja ein “Mutterrepository” und sollte daher beim Klon nicht auftauchen.

    git clone <pfad des="" mutterrepository="" />

  3. Sie finden die Git Flow Darstellung auch im Hintergrund des Titelbildes dieses Büchleins. Mir gefällt der Ansatz gut - allerdings wollte ich hier allgemeiner über den Umgang mit Git berichten.