Softwareentwicklung

12.7 Versionsmanagement mit Git

Eine sogenannte Versionsverwaltung (engl. Version Control System – VCS) ermöglicht Ihnen das Archivieren, Rekonstruieren und Vergleichen verschiedener Stände elektronischer Daten, insbesondere textueller Inhalte wie Quellcode. So können Sie sich beispielsweise ansehen, wie sich ein Quelltext oder eine Textdatei im Laufe der Zeit verändert hat. Wir benutzen eine Versionsverwaltung jedoch auch für den LaTeX-Quelltext dieses Buches, um sämtliche Änderungen sichtbar zu machen und Versionsstände zu archivieren sowie auszutauschen. Sämtliche Daten eines Projekts packt man dazu in einen Speicherbereich, den man Repository nennt.

Tools für die Versionsverwaltung gibt es viele, darunter einige historische wie RCS und CVS. Hier und da kommen auch noch das lange Zeit populäre Subversion (SVN) oder Systeme wie Mercurial zum Einsatz. Auch wenn wir selbst lange an CVS und SVN hingen: Seit einigen Jahren kommt eigentlich niemand mehr an Git vorbei. Git wurde 2005 veröffentlicht und ist auf das verteilte Arbeiten mit Versionsständen ausgelegt. Es wurde von den Entwicklerinnen und Entwicklern des Linux-Kernels konzipiert und wird von diesen verwendet, um den Kernel weiterzuentwickeln. Am Kernel-Repository arbeiten folglich sehr viele Entwicklerinnen und Entwickler weltweit verteilt. Auch die bekannten Plattformen github.com und sourceforge.net bieten (kostenfreie) Git-Repositories an, mit denen Sie ohne große Hürden Git ausprobieren können.

Bei verteilten Versionsverwaltungen (engl. Distributed Version Control Systems – DVCS) wie Git laden sämtliche Clients eine Kopie des gesamten Repositorys herunter und wären theoretisch jederzeit in der Lage, selbst als Git-Server zu fungieren. Der Ausfall eines zentralen Servers mit einer »Masterversion« (wie bspw. bei CVS) ist daher kein Problem.

12.7.1 Ein wenig Theorie zur Einführung

Git verwaltet Zwischenstände (sog. Snapshots). Snapshots entsprechen dem kompletten Datenstand eines Projekts zu einem Zeitpunkt. Lokale Änderungen führen damit wieder zu einem neuen Snapshot, und zwar auch dann, wenn nur eine von vielen Dateien eines Projekts modifiziert wurde. Aber keine Sorge, Git speichert unveränderte Dateien für Snapshots nicht als Kopien ab. Stattdessen wird schlicht auf vorherige Dateiversionen referenziert, womit viel Speicherplatz gespart wird. Dadurch, dass jeder Git-Client auf Snapshotbasis agiert, kann er auch Änderungen zu alten Versionen lokal anzeigen, ohne diese bei einem zentralen Server anzufragen.

12.7.2 Arbeiten mit Git

Zwar können wir Ihnen an dieser Stelle nicht sämtliche Informationen zum Umgang mit Git liefern, möchten Ihnen jedoch die wichtigsten Schritte für den Erstkontakt erläutern.

Klonen

Probieren wir es doch einmal aus. Typischerweise möchten Sie zunächst ein bestehendes Repository im aktuellen Stand laden, was als Klonen bezeichnet wird. Wenn git installiert ist, geht dies ganz einfach mit dem Parameter clone und einer URL, die Sie vom jeweiligen Repository erhalten. Hier checken wir beispielsweise das Repository NELphase von GitHub aus, das Sie unter https://github.com/cdpxe/NELphase finden:

$ git clone https://github.com/cdpxe/NELphase.git
Klone nach 'NELphase' ...
remote: Enumerating objects: 367, done.
remote: Counting objects: 100% (172/172), done.
remote: Compressing objects: 100% (117/117), done.
remote: Total 367 (delta 109), reused 110 (delta 51), pack-reused 195
Empfange Objekte: 100% (367/367), 108.62 KiB | 1.34 MiB/s, fertig.
Löse Unterschiede auf: 100% (214/214), fertig.

Listing 12.46 Auschecken von NELphase

Das ausgecheckte Repository finden Sie nun im Unterverzeichnis NELphase.

Änderungen beitragen und abholen

Wie bereits erwähnt, nutzen wir Git auch für die Bearbeitung unseres Linux-Buchs. Änderungen führen wir dabei am Quelltext durch. Hat man eine lokale Datei modifiziert, so zeigt git status an, welche Dateien modifiziert wurden. Dabei sehen wir, dass unser Arbeitszweig (der Branch) der master-Branch ist. Sie können für Projekte mehrere Branches definieren, beispielsweise könnte bei einem Softwareprojekt ein Masterbranch die stabile Version der Software enthalten und ein Developmentbranch die aktuelle Entwicklungsversion. Wir gehen in dieser kurzen Einführung nicht weiter auf Branches ein und arbeiten schlicht mit dem master-Branch, den Sie überall finden. Außerdem sehen wir, dass die Datei kap12_Softwareent.tex modifiziert wurde.

$ git status
Auf Branch master
Ihr Branch ist auf demselben Stand wie 'origin/master'.
Änderungen, die nicht zum Commit vorgemerkt sind:
[...]
        geändert:       kap12_Softwareent.tex

Listing 12.47 Wurden Dateien lokal verändert?

Möchten wir nun sehen, wie sich unsere lokale Version von der vorherigen unterscheidet, können wir git diff (zeigt Differenzen für sämtliche Dateien) bzw. git diff datei.txt (für die Datei datei.txt) nutzen.

$ git diff
diff --git a/latex_grundk/kap12_Softwareent.tex
           b/latex_grundk/kap12_Softwareent.tex
index 6540664..5f84e06 100644
--- a/latex_grundk/kap12_Softwareent.tex
+++ b/latex_grundk/kap12_Softwareent.tex
@@ -1049,6 +1049,10 @@ M

-
+Möchten Sie Ihre Änderungen nun beitragen, sodass
+diese für andere Nutzer, die mit dem Repository
+arbeiten, abgerufen werden können, müssen diese mit
+einem beschreibenden Kommentar hinzugefügt werden.
[...]

Listing 12.48 Lokale Änderungen anzeigen

Zeilen, die mit einem Leerzeichen beginnen, sind unverändert, solche mit einem Minuszeichen wurden ersetzt, und Zeilen mit Pluszeichen wurden neu hinzugefügt.

Möchten Sie Ihre Änderungen nun beitragen, sodass diese für andere Nutzer, die mit dem Repository arbeiten, abgerufen werden können, müssen diese mit einem beschreibenden Kommentar hinzugefügt werden.

Zu diesem Zweck fügen Sie mit git add zunächst die Dateien zum Snapshot hinzu, die Sie aktuell beitragen möchten. Mit git commit -m 'Nachricht' können Sie wiederum einen entsprechenden Kommentar zur Beschreibung Ihrer Änderungen festlegen.

$ git add kap12_Softwareent.tex 
$ git commit -m 'Neuer Absatz zu Git'
[master 6863f15] Neuer Absatz zu Git
 1 file changed, 4 insertions(+), 1 deletion(-)

Listing 12.49 git add und commit

Schließlich werden die Änderungen zum gewünschten Branch (in der Regel der master-Branch) mit git push beigetragen.

$ git push origin master
Objekte aufzählen: 7, fertig.
Zähle Objekte: 100% (7/7), fertig.
Delta-Kompression verwendet bis zu 8 Threads.
Komprimiere Objekte: 100% (4/4), fertig.
Schreibe Objekte: 100% (4/4), 910 Bytes | 303.00 KiB/s, fertig.
Gesamt 4 (Delta 3), Wiederverwendet 0 (Delta 0)
To project-gitlab.xxxxxxxxxx.de:wendzel/linux-grundkurs.git
   3e00c91..6863f15  master -> master

Listing 12.50 git push

Änderungen, die von einem anderen Rechner beigetragen wurden, können Sie übrigens mit git pull abholen. Somit können Sie Ihr Repository immer auf dem aktuellen Stand halten.

Sie möchten mehr zum Thema Git erfahren? Werfen Sie doch einmal einen Blick in das Git-Handbuch unter https://git-scm.com/book/de/v2.