Git-Tutorial: Die ersten Schritte mit dem Ver­si­ons­kon­troll­sys­tem

Die ge­mein­sa­me Ent­wick­lung von Software-Projekten findet nicht nur innerhalb von Firmen statt: Auch im Open-Source-Sektor sind – je nach Pro­jekt­grö­ße – mehrere hunderte bis tausende Frei­wil­li­ge und Eh­ren­amt­li­che an der In­stand­hal­tung, Op­ti­mie­rung, Wei­ter­ent­wick­lung oder Mo­di­fi­zie­rung eines Programms beteiligt. Ohne ein passendes System zur Auf­zeich­nung und Kontrolle der zahl­rei­chen Än­de­run­gen durch die ver­schie­de­nen Ent­wick­ler wären derartige Projekte kaum zu rea­li­sie­ren.

Eine der be­lieb­tes­ten Lösungen zur Ver­si­ons­ver­wal­tung ist das li­zenz­freie Tool Git, das einfach zu lernen und gänzlich kos­ten­frei nutzbar ist. In diesem Tutorial ver­mit­teln wir Ihnen alle wichtigen Git-Grund­la­gen, die Sie für den Einstieg in das Ver­si­ons­ver­wal­tungs­pro­gramm benötigen.

Git ist ein ver­teil­tes Ver­si­ons­ver­wal­tungs­sys­tem, das 2005 von Linux-Schöpfer Linus Thorvalds ent­wi­ckelt und unter der freien GNU-GPLv2-Lizenz ver­öf­fent­licht wurde. Die Be­son­der­heit des Tools besteht darin, dass zwar ein zentrales Re­po­si­to­ry für jedes Projekt existiert, alle be­tei­lig­ten Nutzer sich aber eine lokale Ar­beits­ko­pie dieses Ver­zeich­nis­ses auf das eigene Ar­beits­ge­rät her­un­ter­la­den. Jede dieser Kopien stellt ein voll­stän­di­ges Back-up des Re­po­si­to­rys dar, weshalb eine durch­ge­hen­de Netz­werk­ver­bin­dung für den grund­le­gen­den Ar­beits­pro­zess nicht er­for­der­lich ist. Zudem dienen die Kopien als Ab­si­che­rung, falls das Haupt-Ver­zeich­nis ausfallen sollte oder be­schä­digt ist. Vor­ge­nom­me­ne Än­de­run­gen können jederzeit mit allen anderen Pro­jekt­teil­neh­mern aus­ge­tauscht und – sofern relevant – in das Re­po­si­to­ry auf­ge­nom­men werden.

Wer das Software-Ma­nage­ment mit Git lernen möchte, der sollte sich im ersten Schritt mit der Software und ihrer Be­nut­zer­ober­flä­che vertraut machen. Git ist für Windows, Unix/Linux und macOS verfügbar, wobei sich die ver­schie­de­nen Versionen hin­sicht­lich ihrer Bedienung leicht von­ein­an­der un­ter­schei­den. Nach der je­wei­li­gen Stan­dard­in­stal­la­ti­on können Sie das Tool platt­form­un­ab­hän­gig entweder über die Kom­man­do­zei­le oder über ein gra­fi­sches Benutzer-Interface steuern.

Binäre In­stal­la­ti­ons­da­tei­en, An­lei­tun­gen für Pa­ket­ma­na­ger-In­stal­la­tio­nen (Unix-Systeme) sowie ein­satz­fer­ti­ge portable Editionen für die einzelnen Systeme finden Sie auf der of­fi­zi­el­len Homepage des Git-Projekts. Laden Sie sich einfach das ge­wünsch­te Paket herunter bzw. greifen Sie auf das passende Paket in Ihrer Paket-Ver­wal­tung zurück und folgen Sie an­schlie­ßend den An­wei­sun­gen des In­stal­la­ti­ons­as­sis­ten­ten. Bei einer portablen Edition entfällt der In­stal­la­ti­ons­schritt selbst­ver­ständ­lich.

Sobald Git auf dem eigenen System in­stal­liert ist, können Sie das Ver­si­ons­ver­wal­tungs­sys­tem für das Ma­nage­ment Ihrer Projekte verwenden. Wie bei jeglicher Software gilt es aber zunächst, die ele­men­ta­ren Funk­tio­nen und Befehle zu verstehen, um den maximalen Nutzen aus der Anwendung ziehen zu können. Im Rahmen unseres großen Git-Tutorials für Ein­stei­ger erläutern wir die wich­tigs­ten Schritte der Git-Ein­rich­tung und -Bedienung über die Kom­man­do­zei­le, sodass Sie im Anschluss pro­blem­los Ihr eigenes Re­po­si­to­ry ein­rich­ten und verwalten können.

Das Git-Respo­si­to­ry ist das zentrale Ver­zeich­nis eines ver­wal­te­ten Projekts und somit auch die zentrale An­lauf­stel­le für alle Teil­neh­mer, über die die komplette Ver­si­ons­kon­trol­le reguliert wird. Ihr erster Schritt in Git besteht dem­entspre­chend darin, ein solches Haupt­ver­zeich­nis zu erstellen – oder zu klonen (in Form einer Ar­beits­ko­pie), sofern Sie sich einem Projekt an­schlie­ßen, dessen ge­mein­sa­me Ent­wick­lung bereits mithilfe von Git kon­trol­liert wird.

Wollen Sie die Ver­si­ons­kon­trol­le neu ein­rich­ten oder haben Sie das Tool zunächst einfach nur in­stal­liert, um die Ar­beits­wei­se mit Git zu lernen, steht zunächst die Neu­erstel­lung eines Re­po­si­to­rys an. Zu diesem Zweck wechseln Sie per „cd“ (change directory) in das ge­wünsch­te lokale Ver­zeich­nis auf Ihrem Gerät:

Dort führen Sie nun den folgenden Befehl aus, um ein .git-Ver­zeich­nis zu erzeugen:

Existiert das Git-Re­po­si­to­ry für Ihr Projekt bereits, benötigen Sie lediglich die Web- bzw. Netz­werk­adres­se zu diesem Ver­zeich­nis, um mit dem Kommando „git clone“ eine Ar­beits­ko­pie auf Ihrem Rechner zu erzeugen:

Zu den wich­tigs­ten Git-Grund­la­gen zählt eine gute Or­ga­ni­sa­ti­on des eigenen Ar­beits­ver­zeich­nis­ses. Über dieses schlagen Sie nicht nur eigene Än­de­run­gen und Neue­run­gen an einem Projekt vor, die an­schlie­ßend per Commit („Frei­schal­tung“) über­nom­men werden, sondern beziehen auch In­for­ma­tio­nen über die Ak­ti­vi­tä­ten anderer Nutzer. Die Ak­tua­li­tät Ihrer Ar­beits­ko­pie können Sie über folgende Eingabe über­prü­fen:

Um eine eigene, neue Datei zur Ver­si­ons­ver­wal­tung hin­zu­zu­fü­gen oder eine über­ar­bei­te­te Datei für den nächsten Commit an­zu­mel­den, wenden Sie den Befehl „git add“ auf diese Datei an (diese muss sich hierfür im Ar­beits­ver­zeich­nis befinden). In unserem Git-Tutorial fügen wir ex­em­pla­risch ein Text­do­ku­ment mit dem Namen „Test“ hinzu:

Sämtliche Än­de­run­gen, die Sie (wie im vor­he­ri­gen Abschnitt be­schrie­ben) für die Ver­si­ons­ver­wal­tung an­ge­mel­det haben, müssen immer per Commit bestätigt werden, damit sie in den HEAD auf­ge­nom­men werden. Beim HEAD handelt es sich um eine Art Index, der auf den letzten wirksam ge­wor­de­nen Commit in Ihrer aktuellen Git-Ar­beits­um­ge­bung (auch als „Branch“ be­zeich­net) verweist. Das Kommando für diesen Schritt lautet:

Wie der Screen­shot zeigt, erhalten Sie nach der Aus­füh­rung von „git commit“ eine zu­sam­men­fas­sen­de Meldung zu dem Commit: In den vor­an­ste­hen­den eckigen Klammern steht zum einen der Name der Branch (Pro­jekt­zweig; hier „master“, da unser Ar­beits­ver­zeich­nis gleich­zei­tig auch das Haupt­ver­zeich­nis ist), in den die Än­de­run­gen über­tra­gen wurden, zum anderen die SHA-1-Prüfsumme des Commits (hier „c0fdc90“). Es folgen der frei gewählte Kommentar (hier „Test“) und konkrete In­for­ma­tio­nen über die vor­ge­nom­me­nen An­pas­sun­gen.

Wenn Sie Än­de­run­gen in Form eines Commits über­nom­men haben, können Sie den Inhalt nach­träg­lich jederzeit über­ar­bei­ten oder ihn gänzlich zu­rück­neh­men. Ein typischer Fall, bei dem An­pas­sun­gen notwendig sind, ist bei­spiels­wei­se der, dass Sie den Commit zu früh generiert und einige wichtige Dateien bzw. An­pas­sun­gen vergessen haben. In diesem Fall gilt es, die neuen bzw. an­ge­pass­ten Dateien nach­träg­lich per „git add“ be­reit­zu­stel­len und die Ein­tra­gung ins Haupt-Re­po­si­to­ry wie­der­ho­len. Hierfür hängen Sie dem Stan­dard­be­fehl die Option --amend an:

Wollen Sie den zuletzt ge­ne­rier­ten Commit hingegen wieder zu­rück­neh­men, gelingt dies mit folgendem Git-Kommando:

Durch dieses Kommando wird der zuletzt in den HEAD auf­ge­nom­me­ne Commit zu­rück­ge­nom­men. Die darin ent­hal­te­nen Dateien werden dabei wieder in den Status als „geplante Än­de­run­gen für den nächsten Commit“ zu­rück­ge­setzt. Sollen die Ar­beits­da­ten hingegen gänzlich gelöscht werden, verwenden Sie anstelle des vor­an­ste­hen­den Kommandos folgenden Befehl:

Das Pro­jekt­ma­nage­ment mit Git zu lernen, lohnt sich ins­be­son­de­re aufgrund der ele­men­ta­ren Ver­sio­nie­rungs-Features. Ein großes Plus des Open-Source-Systems besteht darin, dass Sie sich jederzeit anzeigen lassen können, welche Än­de­run­gen zuletzt am Re­po­si­to­ry vor­ge­nom­men worden sind. Der hierfür benötigte Git-Befehl lautet:

Das log-Kommando lässt sich außerdem mithilfe ver­schie­de­ner Parameter mo­di­fi­zie­ren. Einige nützliche Optionen sind in der nach­fol­gen­den Tabelle auf­ge­führt:

Bis hierhin haben wir in diesem Git-Tutorial auf­ge­zeigt, wie Sie Än­de­run­gen als Commit im HEAD des lokalen Ver­zeich­nis­ses speichern. Damit diese aber auch in das Haupt-Re­po­si­to­ry auf­ge­nom­men werden, ist die Eingabe folgenden Befehls er­for­der­lich:

Durch ihn überträgt Git au­to­ma­tisch alle er­stell­ten Commits, die bisher nur in der Ar­beits­ko­pie vorhanden waren, in das Haupt­ver­zeich­nis, das auch die Be­zeich­nung „master“ hat. Ersetzen Sie diesen Namen in dem auf­ge­führ­ten Code durch den eines anderen Branches (Pro­jekt­zweigs), werden die Dateien statt­des­sen direkt dorthin gesendet.

Wie viele andere Ver­si­ons­kon­troll­sys­te­me verfügt auch Git über eine Tagging-Funktion, mit der sich aus­ge­wähl­te Punkte in der Historie eines Re­po­si­to­rys als wichtig markieren lassen. Ty­pi­scher­wei­se werden solche Tags dazu verwendet, Releases einer Software wie Version 1.0, 2.0 usw. zu kenn­zeich­nen, damit diese auch bei großen Projekten jederzeit leicht abrufbar bleiben. Git un­ter­stützt dabei zwei Arten von Tags:

• An­no­tier­te Tags („annotated“) werden als ei­gen­stän­di­ge Objekte in der Datenbank ge­spei­chert, inklusive eigener Prüfsumme, Tagging-Meldung, Datum, Name und Mail-Adresse des Tag-Er­stel­lers sowie op­tio­na­ler GNU-Privacy-Guard-Signatur (GPG-Signatur).
• Nicht-an­no­tier­te Tags („light­weight“) fungieren – ähnlich wie Branches – aus­schließ­lich als Verweis auf einen Commit. Dieser Typ bietet sich dann an, wenn Sie lediglich temporäre Tags benötigen oder die er­wei­ter­ten In­for­ma­tio­nen nicht speichern wollen.

An­no­tier­te Tags erstellen Sie in Git, indem Sie den Befehl „git tag -a“ auf den ge­wünsch­ten Commit anwenden. Hängen Sie außerdem den Parameter „-m“ an, können Sie – in gerade An­füh­rungs­zei­chen gesetzt – auch direkt in der Kom­man­do­zei­le die ge­wünsch­te Tagging-Meldung for­mu­lie­ren. In diesem Git-Tutorial haben wir den Commit „Test“ generiert, den wir zu diesem Zweck auch mit einem Tag inklusive der Meldung „example tag“ ver­knüp­fen:

Für nicht-an­no­tier­te Tags gehen Sie ähnlich vor: Al­ler­dings wenden Sie aus­schließ­lich den Grund­be­fehl „git tag“ auf den ge­wünsch­ten Commit an und ver­zich­ten auf weitere Parameter. Für unser Git-Tutorial-Beispiel würde dies folgendes Kommando bedeuten:

Sobald Tags für Ihr Re­po­si­to­ry exis­tie­ren, können Sie sich diese mit dem bereits bekannten „git tag“ und den op­tio­na­len Pa­ra­me­tern „-l“ bzw. „--list“ anzeigen lassen:

Um einen Tag aus dem lokalen Ar­beits­ver­zeich­nis zu löschen, wenden Sie die Be­fehls­ket­te „git tag -d“ auf diesen an. Unseren Verweis auf „Test“ entfernt man also fol­gen­der­ma­ßen:

Auch Tags müssen Sie im Übrigen wie Commits manuell in das Haupt­ver­zeich­nis über­tra­gen. Dafür werden der Tag-Name sowie das Kommando „git push origin“ benötigt. Statt des Tag-Namens können Sie aber auch den Parameter „--tags“ anhängen, wodurch alle ge­ne­rier­ten Tags im Re­po­si­to­ry auf­ge­nom­men werden:

Die in diesem Git-Tutorial bereits erwähnten Branches stellen im Prinzip nichts Anderes als einzelne Ar­beits­ver­sio­nen des Haupt-Respo­si­to­rys dar, das selbst als Branch – mit dem Namen „master“ – ein­ge­stuft wird. Mit diesen Ar­beits­zwei­gen bietet Git die perfekte Grundlage dafür, Features und Funk­tio­nen isoliert von­ein­an­der zu ent­wi­ckeln und erst zu einem späteren Zeitpunkt zu­sam­men­zu­füh­ren. Letzteres be­zeich­net man auch als „mergen“ (von engl. merge „ver­schmel­zen“).

Einen neuen Branch zu erstellen, ist nicht schwer: Sie benötigen lediglich die Anweisung „git branch“ und hängen dieser die ge­wünsch­te Be­zeich­nung für den Zweig an. Einen Beispiel-Branch mit dem Namen „test_branch“ erstellen Sie bei­spiels­wei­se auf folgende Weise:

An­schlie­ßend können Sie jederzeit mit der Anweisung „git checkout“ in diesen Branch wechseln:

Wollen Sie Branches zu­sam­men­füh­ren, gelingt dies mit dem Kommando „git merge“. Wechseln Sie zunächst via „checkout“ in das Ver­zeich­nis, das einen anderen Zweig aufnehmen soll und führen Sie dort dann den genannten Befehl inklusive des Namens des auf­zu­neh­men­den Branchs aus. Unsere Ar­beits­ver­si­on „test_branch“ lässt sich bei­spiels­wei­se fol­gen­der­ma­ßen in das Haupt-Re­po­si­to­ry mergen:

Haben Sie Ar­beits­zwei­ge zu­sam­men­ge­führt und benötigen daher einen be­stimm­ten Branch nicht mehr, können Sie diesen ganz einfach löschen. Zu diesem Zweck wenden Sie die Be­fehls­fol­ge „git branch -d“ auf den nicht mehr be­nö­tig­ten Ver­si­ons­zweig an. Unser Git-Tutorial-Beispiel „test_branch“ lässt sich durch folgende Eingabe entfernen: