Die Arbeit an Software gerät mitunter schnell unübersichtlich. Mit dem VCS Git erleichtern Sie sich den Umgang mit komplexem Code erheblich.

Sie arbeiten an einem Programm oder einer Web-Präsenz? Sie erstellen von Zeit zu Zeit Sammlungen von Dateien? Sie arbeiten im Team an einem übergreifenden Projekt, wobei jeder Änderungen vornehmen darf? Verwenden Sie zum Verwalten der Daten bislang noch kein Versionsverwaltungssystem, lohnt sich ein Blick auf das flexible Werkzeug Git auf alle Fälle.

Mit Git fällt es leicht, unterschiedliche Versionen von Dateien nebeneinander zu managen. Die Software steht unter der GPLv2 und gehört somit zu den freien Programmen. Es verbreitet sich zunehmend und hat seine Leistungsfähigkeit bereits in sehr umfangreichen Projekten, wie etwa dem Linux-Kernel, bewiesen.

Die Software arbeitet dezentral, eine Server-Anbindung ist nur zum Synchronisieren erforderlich. Die tägliche Arbeit, die sich je nach Aufgabe unterschiedlich lange hinzieht, erfolgt in der Regel lokal, was die Abläufe erheblich beschleunigt. Die Reifezeit von über zehn Jahren bedingt, dass Git gerade für Einsteiger in die Welt der Versionsverwaltungssysteme überraschend einfach zu bedienen ist [1].

Vor dem Start

Das Programmpaket Git ist Bestandteil nahezu aller Distributionen. Die Installation erfolgt bei Systemen, die auf Red Hat basieren, mit sudo yum install git, bei Ubuntu mit sudo apt install git.

Zunächst sollten Sie Namen und die Mail-Adresse konfigurieren. Ohne diese Informationen gibt Git entweder eine entsprechende Warnung aus oder generiert diese Daten aus dem Rechner- und dem Benutzernamen. Letzteres ist meist nicht gewollt. Für den Benutzer Otto Muster mit der E-Mail-Adresse otto.muster@example.org sieht das aus wie in Listing 1.

$ git config --global user.name "Otto Muster"
$ git config --global user.email otto.muster@example.org
$ git config --list
user.name=Otto Muster
user.email=otto.muster@example.org

Das Kommando git config --list zeigt die Einstellungen an. Diese ändern Sie bei Bedarf jederzeit. Git verwendet einen mehrstufigen Aufbau dieser Einstellungen (siehe Kasten “Frage der Einstellung”).

Auf geht’s

Das Projekt im Beispiel liegt im Verzeichnis ~/mprojekt und besteht aus den Textdateien liesmich.txt und projekt.txt. Die Kommandos aus Listing 2 legen das Projekt an, erzeugen aber noch kein Repository.

$ cd
$ mkdir mprojekt
$ cd mprojekt
$ echo "Datei liesmich.txt" > liesmich.txt
$ echo "Datei projekt.txt" > projekt.txt

Der Erstellen des eigentlichen Repositorys umfasst drei Schritte (Listing 3): Zuerst initialisieren Sie im Hauptverzeichnis, in diesem Fall ~/mprojekt, das Projekt, dann melden Sie die enthaltenen Dateien an und übernehmen diese in die Git-Datenbank, das Projektarchiv.

$ cd ~/mprojekt
$ git init
Leeres Git-Repository in /home/otto/mprojekt/.git/ initialisiert
$ git add liesmich.txt 
$ git add projekt.txt
$ git commit -m "Erster Commit"
[master (Basis-Commit) 77558e4] Erster Commit
 2 files changed, 2 insertions(+)
 create mode 100644 liesmich.txt
 create mode 100644 projekt.txt

Das Kommando git init legt ein leeres Repository im Unterverzeichnis .git an (einem versteckten Verzeichnis). Dabei ist es egal, ob sich Dateien im eigentlichen Verzeichnis befinden oder nicht, projektspezifische Daten berücksichtigt Git dabei nicht.

Mit dem Kommando git add fügen Sie eine Datei dem Index hinzu. Der zu diesem Zeitpunkt aktuelle Stand der Datei befindet sich jetzt in der sogenannten Staging Area. Diese enthält Versionen, die für den nächsten Commit vorgemerkt sind. Im Git-Jargon ausgedrückt: Die Datei ist “gestaged”.

Das Kommando git commit übernimmt die vorgemerkten Dateien ins Projektarchiv. Dieser Vorgang heißt Commit oder Einchecken. Zu jedem Commit gehört ein entsprechender Text. Git zeigt die erste Zeile des Textes bei verschiedenen Ausgaben an; sie sollte daher kurz und möglichst präzise sein. Durch eine Leerzeile abgetrennt dürfen Sie den Commit dann noch ausführlich beschreiben.

Diesen Text übergeben Sie mit der Option -m an die Software. Ohne diese Option startet Git, sofern nicht anders konfiguriert, den voreingestellten Editor (Abbildung 1). Erfolgt hier ebenfalls keine Eingabe, bricht Git den Commit ab.

Abbildung 1: Ein Commit ohne die Angabe eines Textes bringt den Systemeditor auf den Schirm.

Richtig verwaltet

Ein Versionsverwaltungssystem, kurz VCS für Version Control System, verwaltet Versionen, genauer gesagt Versionen von Dateien. Eine solche gibt es dann, wenn Sie eine Datei dem Projekt hinzufügen oder eine bereits im Projekt enthaltene Datei bearbeiten. Über dieses System definieren Sie letztendlich die Version eines Projekts, wie etwa eines Programms oder einer Webseite.

Ein VCS protokolliert wer, wann, warum, welche Änderungen durchgeführt hat. Das ermöglicht es, diese nachzuvollziehen, unterschiedliche Versionen zu vergleichen sowie vorherige Stände wiederherzustellen. Zudem bringt es die Änderungen auf den Schirm, die Projektmitglieder parallel gemacht haben.

Die Software verwaltet die Dateien in einem Repository, kurz Repo, also einem Verzeichnis [2]. Da die Arbeit in der Regel in einer Kopie geschieht, und das Original typischerweise in einem anderen Verzeichnis, idealerweise auf einem anderen physikalischen Medium liegt, entsteht in diesem Fall automatisch eine Form der Sicherheitskopie.

Arbeiten mehrere Personen an einem Projekt, ist der Einsatz eines VCS eigentlich Pflicht. Ohne gerät das Synchronisieren schnell zum Problem. Der Einsatz von Git in eigenen, sogar in sehr kleinen Projekten, lohnt sich jedoch durchaus.

Versionen

Innerhalb eines mit Git versionierten Projekts liegt eine Datei in drei Versionen vor (Abbildung 2). Die Version im Working Directory, zu Deutsch Arbeitsverzeichnis, ist die, an der Sie arbeiten. Hat die Datei einen Zustand erreicht, den Sie erhalten wollen, übernehmen Sie diesen mit git add Datei in die Staging Area und arbeiten an der Version im Arbeitsverzeichnis weiter.

Abbildung 2: Arbeiten Sie mit Git, um Dateien in einem Projekt zu verwalten, haben Sie es mit mehreren möglichen Zuständen und Positionen der Dateien zu tun.

Diesen Vorgang dürfen Sie beliebig oft wiederholen. Dabei überschreiben Sie aber jeweils die vorhergehende Version in der Staging Area. Für jede Datei existiert genau eine Version in der Staging Area. Ein eventuell folgender Commit übernimmt diese letzte Version. Die Version im Arbeitsverzeichnis spielt dabei keine Rolle.

Abbildung 3 zeigt die Datei projekt.txt in zwei unterschiedlichen Versionen, eine Version liegt in der Staging Area und eine zweite im Arbeitsverzeichnis. Das Projektarchiv enthält die dritte Version.

Abbildung 3: Zwei Versionen einer Datei und mögliche Anweisungen, um mit diesen zu arbeiten.

Git gibt beim Ausführen einiger Kommandos weitere, spezifische Hinweise. Diese beziehen sich meist darauf, wie Sie eine bestimmte Aktion rückgängig machen.

Hilfe

Die Installation bringt neben dem generellen Handbuch (man git) mehrere spezifische Handbücher mit (siehe Tabelle “Für alle Fälle”). Rufen Sie man git auf, finden Sie im Bereich GIT COMMANDS eine Übersicht der Unterkommandos, inklusive einer kurzen Beschreibung (Abbildung 4).

Eine weitere Dokumentation befindet sich im Verzeichnis /usr/share/doc/git. Deren Umfang hängt von der Distribution ab. Fedora bringt etwa ein Handbuch für Anwender mit dem Dateinamen user-manual.html und ein How-to in howto-index.html mit. Beide Texte liegen allerdings nur auf Englisch vor. Wollen Sie sich umfassend informieren, bietet sich darüber hinaus das Buch ProGit an, das online auf Deutsch bereitsteht [3].

Abbildung 4: Das Handbuch man git gibt Ihnen einen schnellen Überblick über den Einsatz des VCS. Weitere Handbücher geben einen Einblick in den Ablauf eines Projekts mit Git.

Die im Handbuch verwendete Syntax unterscheidet sich von der üblichen Schreibweise dahingehend, dass die unterschiedlichen Kommandos über einen Bindestrich mit dem Wort git verbunden sind. Die Aufrufe git help Kommando und man git-Kommando zeigen die zu Kommando jeweils passende Seite an.

Das in der Abbildung 4 gezeigte Kommando git-add ist ein Index auf die Seite zu git add. Der zugehörige Aufruf ist man git-add (Abbildung 5).

Abbildung 5: Neben einer Seite mit allgemeinen Informationen finden sich bei vielen Distributionen noch zusätzlich Seiten, die den Einsatz der jeweiligen Unterkommandos erläutern.

Direkte Hilfe

Alle im Test verwendeten Distributionen unterstützten das automatische Vervollständigen der Git-Kommandos und deren Optionen über [Tabulator]+. Der Auszug aus Listing 4, Zeile 1 und Zeile 2, zeigt die Ausgabe nach der Eingabe von git a gefolgt von [Tabulator]. In diesem Fall gibt es, wie meistens, mehrere Optionen. Der Aufruf git --help (Listing 4, Zeile 3) zeigt einen Auszug aus der nach Aufgaben gegliederten Übersicht über die Git-Kommandos.

$ git a
add    am    annotate    apply    archive
$ git --help
Verwendung: git ... <command> [<args>]

Projekt fortführen

Im weiteren Verlauf ändert sich die Datei projekt.txt. Diese Versionen übernehmen Sie mit den Kommandos add und commit. Das Kommando git status zeigt den Status der Dateien im Arbeitsverzeichnis an. In Listing 5 ist zu sehen, wie sich der Status der Datei projekt.txt nach dem Kommando git add projekt.txt von Änderungen, die nicht zum Commit vorgemerkt sind zu zum Commit vorgemerkte Änderungen hin ändert.

$ echo "neue Zeile" >> projekt.txt 
$ git status 
Auf Branch master
Änderungen, die nicht zum Commit vorgemerkt sind:
  (benutzen Sie "git add <Datei>...", um die Änderungen zum Commit vorzumerken)
  (benutzen Sie "git checkout -- <Datei>...", um die Änderungen im Arbeitsverzeichnis zu verwerfen)
        geändert:       projekt.txt
keine Änderungen zum Commit vorgemerkt (benutzen Sie "git add" und/oder "git commit -a")
$ git add projekt.txt
$ git status
Auf Branch master
zum Commit vorgemerkte Änderungen:
  (benutzen Sie "git reset HEAD <Datei>..." zum Entfernen aus der Staging-Area)
        geändert:       projekt.txt
$ git commit -m "neue Zeile eingefügt"
[master 9d71c8d] neue Zeile eingefügt
 1 file changed, 1 insertion(+)

Der Befehl git add unterstützt dabei die Angabe von Mustern für Dateien und Verzeichnisse sowie weitere Optionen. Über git add -u bringen Sie alle im Index eingetragenen, modifizierten Dateien in die Staging Area. Die Tabelle “Für den Einstieg” zeigt die bisher verwendeten Kommandos.

Und jetzt?

Git verwaltet jetzt das Projekt, aber was bringt es nun effektiv? Zunächst mal die History, die Sie mit git log einsehen. Der Auszug aus Listing 6 zeigt ein Projekt mit zwei Commits, was zwei Versionen entspricht.

$ git log
commit 9d71c8dd00db5bfb7e21ac8884356d0af284b1b8 (HEAD -> master)
Author: Otto Muster <otto.muster@muster.de>
Date:   Fri May 11 15:22:13 2018 +0200
    neue Zeile eingefügt
commit e29f38d1bc7625090
Author: Otto Muster <otto.muster@muster.de>
Date:   Thu May 10 09:35:53 2018 +0200
    Erster Commit

Jeder Commit ist mit einem 40-stelligen SHA1-Hash, im Folgenden als nur Hash genannt, gekennzeichnet. Dieser dient zum eindeutigen Identifizieren und als Checksumme. Bei einigen Kommandos ist es möglich, den Hash als Parameter anzugeben, wobei die Angabe der ersten 8 bis 10 Stellen oft ausreicht.

So gibt das Kommando git log 77558e4ac nur die Log-Nachricht bis zum angegebenen Commit aus. Im Terminal funktioniert das Kopieren und Einfügen des Hash mit der Maus, indem Sie mit der linken Maustaste auf den Hash doppelt klicken und ihn über einen einfachen Klick mit der mittleren Maustaste wieder einfügen.

Die Tabelle “Erweiterte Kommandos” enthält einige Kommandos inklusive möglicher Optionen für den Umgang mit den versionierten Daten. Zu jedem gibt es eine Vielzahl weiterer Optionen. Ein Blick in die spezifische Seite des Handbuchs zeigt diese an.

Das Kommando ist git difftool verhält sich wie git diff, startet jedoch ein externes Programm (Abbildung 6). Git sucht dabei nach typischen Programmen dieser Art. Über das Kommando git config --global diff.tool Programm> legen Sie bei Bedarf eins fest.

Abbildung 6: Mit dem Befehl git difftool rufen Sie ein externes Programm zum Betrachten der Unterschiede zwischen Dateien auf, im Beispiel Meld.

Remote-Repository

Bisher gibt es nur das lokale, im Projektverzeichnis befindliche Repository. Ein typisches Projekt stammt jedoch in der Regel aus einem sogenannten Remote Repository. Dieses klonen Sie lokal, was letztendlich einer exakten Kopie der entfernten Daten nebst den Metadaten für Git entspricht.

Zum Erstellen eines entfernten Repositorys erzeugen Sie aus den lokalen Daten ein Bare Repository. Im Vergleich zu dem lokalen Repo enthält dieses kein Arbeitsverzeichnis.

Sie haben dann die Möglichkeit, das Bare Repository in ein entsprechendes Verzeichnis, in Listing 7 ~/gitrepo, zu verschieben. Anschließend dürfen Sie das bestehende Projektverzeichnis umbenennen oder löschen. Das neu erstellte Remote Repository klonen Sie einfach, wobei Git das Unterverzeichnis anlegt.

$ cd ~/mprojekt/../
$ git clone --bare mprojekt mprojekt.git
Klone in Bare-Repository 'mprojekt.git' ...
$ mv mprojekt.git gitrepo
$ cd
$ mkdir gitrepo
$ mv mprojekt/ mprojekt_old
$ cd
$ git clone /home/otto/gitrepo/mprojekt.git
Klone nach 'mprojekt' ...
$ cd mprojekt
$ git remote show origin
* Remote-Repository origin
  URL zum Abholen: /home/otto/gitrepo/mprojekt.git
  URL zum Versenden: /home/otto/gitrepo/mprojekt.git
  Hauptbranch: master
  Remote-Branch:
    master gefolgt
  Lokaler Branch konfiguriert für 'git pull':
    master führt mit Remote-Branch master zusammen
  Lokale Referenz konfiguriert für 'git push':
    master versendet nach master (aktuell)

Ab jetzt bearbeiten Sie das Projekt im neu erstellten Verzeichnis mprojekt. Der Unterschied ist nun, dass das lokale Repository mit dem Remote Repository gitrepo/mprojekt verbunden ist. Das Kommando git push überträgt die Daten aus dem lokalen Verzeichnis ins entfernte. Damit haben Sie unter Umständen die Daten zusätzlich gesichert, auf jeden Fall aber die Möglichkeit, das Projekt mehrfach an unterschiedlichen Orten auszuchecken.

Fazit

Der Umgang mit Git ist recht einfach, selbst ohne vorherige Kenntnisse im Bereich der Versionskontrollsysteme. Die tägliche Arbeit erledigen Sie mit wenigen Kommandos effizient von der Kommandozeile aus. Da Git die Änderungen meist lokal speichert, geht alles sehr schnell.