Git für Einsteiger – Versionsverwaltung im Projekt

Linus Thorvalds ist nicht nur der Vater des Linux-Kernels, sondern auch der von Git, einer Software zur Versionsverwaltung von Quellcode. Versionieren lassen sich damit aber auch andere Projekte, in denen bestimmte Entwicklungsstufen festgehalten und wiederherstellbar sein sollen: Dokumente, Grafiken oder Projektstände. Das System funktioniert am einfachsten mit Konsolebefehlen, es gibt aber auch grafische Tools dazu.

Die Grundbegriffe von Git erscheinen im ersten Moment etwas wirr, haben aber eine eigene Logik, an die man sich schnell gewöhnt. In dieser Anleitung für Einsteiger gehen wir sie Schritt für Schritt durch.

Grundlagen: So funktioniert Git

Git verfügt über drei Arbeitsebenen: Das Arbeitsverzeichnis, die Stage und das Repository. Manchmal kommt noch ein zentrales Team-Repository hinzu. Im Arbeitsverzeichnis arbeitet der Anwender – wie der Name schon sag, legt dort seine Projektdateien ab, ändert sie oder löscht einzelne wieder.

Will er einen Stand seiner Arbeit speichern, so übergibt er die Änderungen zur Vorgängerversion erstmal der Stage. Das ist eine Art automatisierter Zusammenfassung aller Änderungen zur Kontrolle, bevor alles endgültig in das Repository wandert. Eine Versionierung im Repository heißt bei Git ein Commit. In einer Team-Umgebung gibt es noch ein zentrales Repository, mit dem der Anwender seine Daten synchronisiert.

Die Zustände oder Commits des Projekts reihen sich also hintereinander wie auf einer Perlenschnur auf. Alle haben einen festen siebenstelligen Hash-Wert. Der letzte, aktuelle Commit nennt sich HEAD.

In komplexeren Projekten ist es auch möglich, mehrere Stränge zu betreiben, die irgendwann vom Hauptstrang (Master oder Main) abzweigen, eigene Wege gehen, sich aber auch manchmal wieder mit dem Master verbinden können. Ein solcher Seitenast heißt Branch. Oft gib es zum Beispiel eine stabile Programmversion im Master- und eine Entwicklerversion im Seitenast.

Installation

Git ist ein Linux-Programm, es gib aber Windows-Pakete, die eine spezielle Linux-Kommandozeile, die Bash, emulieren. Laden Sie die Installationsdatei von git-scm.com und starten Sie diese. Für Git sollten Sie unter Windows mit Admin-Rechten arbeiten. Die vorgegebenen Optionen bei der Installation sind meist zutreffend, Sie sollten sich aber ein Desktop-Symbol anlegen lassen und den Standard-Editor wechseln, z.B. auf Visual Studio Code oder den Windows-eigenen Editor Notepad.

Tipp: Visual Studio erkennt ein Git-Verzeichnis, und viele hier beschriebenen Befehle lassen sich im Editor mit Tastenklick erledigen.

Tipp: Git kommt mit dem Vim-Editor, der nicht jedermanns Sache ist. Wenn man in Vim landet, z.B. bei Log-Befehlen, verlassen Sie diesen wieder mit dem Tastendruck q. Hilfreich aber nicht immer zielführend ist auch Esc.

Erste Konfiguration

Starten Sie nun Git Bash vom Desktop. Es erscheint eine Kommandozeile ähnlich der Windows-Eingabeaufforderung. Führen Sie nun erste Konfigurationsschritte aus, die für alle Projekte, die Sie später anlegen wollen, gelten:

git config --global user.name “Max Meier“

git config -- global user.email “max@meier.de“

Mit

git help config

erhalten Sie weitere Informationen.

Tipp: Alle Hilfsseiten finden sie als HTML im Git-Programmverzeichnis …\mingw64\share\docs\git-doc.

Wechseln Sie nun in das Verzeichnis, in dem sich an Ihrem Projekt arbeiten (Ihr Arbeitsverzeichnis). Standardmäßig startet die Bash-Konsole im Verzeichnis des angemeldeten Users (c:/Users/<Sie>/). Unser Beispiel liegt in einem Ordner auf dem Desktop:

cd ./Desktop/projekt

Nun starten Sie die Versionskontrolle für diesen Ordner. Dabei spielt es keine Rolle, ob sich schon Arbeitsdateien und -ordner darin befinden oder nicht:

git init

Es kommt die Meldung „Inizialized … Git repository in C:/users/<Sie>/Desktop/projekt/.git“

Wie in der Meldung schon ersichtlich, findet sich im Projektordner ein neuer Systemordner .git. Hier liegen alle relevanten Informationen für Git. Sie können diesen Ordner auch von einem anderen Rechner aus ansprechen, der Git installiert hat, und Git holt sich alle relevanten Daten.

Daten mit Git versionieren

Fügen Sie nun Dateien und Ordner in Ihr Arbeitsverzeichnis. Mit

add --all

laden Sie nun alle Dateien in die Stage – die Zwischenebene von Git. Sie können auch nur einzelne Dateien versionieren mit

add eine_datei.txt

Git verwaltet aber immer nur die Dateien, die Sie irgendwann mit Add zugefügt haben. Im zu prüfen, was sich in der Stage befindet, verwenden Sie:

git status

Es erscheint die Meldung „on branch master“, was auf den Zweig Master hinweist. Dann „no commits yet“. Alle Änderungen befinden sich als noch in der Stage. Dann folgt eine Liste der Dateien, die Sie mit Add der Bühne hinzugefügt und seit dem letzten Mal geändert haben. In unserem Fall also alle Daten.

Wenn Sie zufrieden mit der Auswahl in der Stage sind, überführen Sie den Zustand in der Stage als Snapshot in das eigentliche Repository:

git commit

Nun öffnet sich der bei der Installation angegebene Editor und Sie geben dort eine Beschreibung Ihres Snapshots ein, die üblicherweise folgende Form hat: Eine Zeile von bis zu 50 Zeichen mit einer Zusammenfassung (z.B. „Version 1.1.9. Kleine Änderungen“), dann eine Leerzeile, dann eine ausführliche Beschreibung der Änderungen im Projekt. Speichern Sie die Datei und schließen Sie sie. Dann übernimmt Git den Commit.

Die Antwort lautet: „master (root-commit) xyzxyzx Version 1.1.9 Kleine Änderungen“ Dann eine Liste der geänderten Dateien. xyzxyzx ist dabei eine eindeutige Hash-Kennung des Systems, über die Sie genau auf diesen Status/Commit zugreifen können. git status wird Ihnen nun sagen: „Nothing to commit“.

Wenn Ihnen statt viel Text ein kurzes Stichwort reicht, sind Sie schneller mit

git commit -m „Version 1.1.9. Kleine Änderungen“

Sie können nun im Arbeitsverzeichnis Dateien ändern oder neue hinzufügen, mit add --all und commit werden diese sicher als Snapshots im Repository hinterleget. git status zeigt ihnen genau an, welche Dateien im Arbeitsverzeichnis geändert oder der Stage zugefügt wurden.

Eine Abkürzung an der Stage vorbei gibt es mit dem Befehl

commit -am „Kommentar“

Er überführt alle geänderten Dateien Ihres Arbeitsverzeichnisses sofort ins Repository, aber Achtung, neue Dateien werden ignoriert. Diese müssen Sie immer über Add der Stage zufügen, um sie dann erst mit Commit ins Repository zu übertragen.

Suchen im Repository

Bislang kennen Sie nur den Befehl Status, der allerdings nur die Stage mit dem Arbeitsverzeichnis vergleicht. Suchen Sie Versionen und Daten im Repository verwenden Sie den Befehl Log. Er ist sehr mächtig, und wenn Sie ihn im vollen Umfang nutzen wollen, helfen Ihnen o.g. Hilfeseiten weiter.

git log --oneline

zeigt Ihnen eine kurze Übersicht über alle Snapshots mit Hash-Wert und Kurzkommentar.

git log --name-only

listet für jede Version nur die geänderten Dateien.

git log -- name-only --oneline --graph

kombiniert beides und stellt es etwas hübscher dar.

git log -p xyzxyzy

schließlich zeigt alle Änderungen eines Commits im Detail, das heißt auch Änderungen innerhalb von nichtbinären Daten (txt, html, js, c etc.). Die Änderungen sind augenfällig Rot markiert. Denken Sie daran: Mit q verlassen Sie den Vim-Editor wieder.

Ansehen und Wiederherstellen einer älteren Version

Um eine vorherige Version (auch nur temporär) wiederherzustellen, gibt es verschiedene Strategien. Die einfachste, effektivste und uneleganteste geht mit Checkout. Hier wird die gewünschte Version der Daten in das Arbeitsverzeichnis kopiert – aber komplett abgetrennt von der Versionsverwaltung (Head detached). Das heißt, Änderungen im Arbeitsverzeichnis lassen sich nicht mehr mit Add und Commit in System zurückspielen.

Als Workaround lassen sich die Dateien aber einfach in einen temporären Ordner kopieren und dann geändert ins System zurückholen. Ein Beispiel. Sie haben vier Versionen im Repository und git log --oneline zeig:

4xxxyyy Kommentar 4 (HEAD -> master)

3xxxyyy Kommentar 3

2xxxyyy Kommentar 2

1xxxyyy Kommentar 1

Der aktuelle Zustand (HEAD vom Master-Zweig) ist Nr. 4. Nun wollen Sie Nr. 2 ansehen oder sogar wiederherstellen. Geben sie ein (Achtung: Alle jetzt vorhanden Dateien im Arbeitsverzeichnis werden gelöscht!):

git checkout 2xxxyyy

Ihr Arbeitsverzeichnis enthält nun die Dateien dieses Snapshots. Kopieren Sie sie z.B. nach C:/temp.

In Git kehren Sie nun in Ihren altes Versionssystem zurück mit

checkout master

Sofort findet sich in Ihrem Arbeitsverzeichnis nun wieder Zustand 4. Nun können Sie den Inhalt ersetzen durch die Dateien im Temp-Ordner. Mit Add und Commit erstellen Sie einen neuen Zustand 5, der dem von 2 entspricht:

5xxxyyy Kommentar 5 (HEAD -> master)

4xxxyyy Kommentar 4

3xxxyyy Kommentar 3

2xxxyyy Kommentar 2

1xxxyyy Kommentar 1

Eine weitere Methode, ältere Zustände wiederzuholen ist Reset. Dieser Befehl ist sehr mächtig und nicht ungefährlich, denn er löscht alle Zwischenstände. Wenn Sie Zustand 2 in unserem Beispiel mit Reset wiederherstellen, sind 3 und 4 unwiederbringlich verloren.

git reset --hard 2xxxyyy

führt mit Log zu

2xxxyyy Kommentar 2 (HEAD -> master)

1xxxyyy Kommentar 1

Dann gibt es noch den Befehl Revert, der gezielt Änderungen eines bestimmten Commits zurücknimmt, aber nur genau diese:

git revert 2xxxyyy

macht genau die Änderungen rückgängig, die Sie in Schritt 2 gemacht haben. Alle anderen, auch spätere Aktionen werden belassen. Haben Sie in Schritt 2 eine Datei hinzugefügt fehlt diese nun. Haben Sie hingegen in Schritt 3 eine Datei zugefügt, die in 2 noch nicht drin war, verbleibt diese. Schwierig wird es, wenn Sie die Datei, die Sie in 2 zugefügt haben, in 3 noch geändert haben. Dann bringt Revert eine Merge-Fehlermeldung.

Wie das Arbeiten mit Git online im Team funktioniert, lesen Sie auf der nächsten Seite.