Git für Einsteiger

Git ist eine frei zugängliche Software, zur Versionsverwaltung von Dateien. Entwickelt wurde Sie eigentlich für die Versionsverwaltung des Linux-Kernels, da das genutzte BitKeeper durch eine Lizenzänderung nicht mehr kostenlos verwendet werden konnte. Linus Torvalds entwickelte daraufhin Git um Anforderungen wie verteilte Arbeitsabläufe, hoher Sicherheit und hohe Effizienz zu erfüllen.

Der größte Vorteil von Git gegenüber SVN ist das verteilte Model. Wogegen SVN einem zentralisieren Modell folgt, d.h. alle Branches und Tags befinden sich in einem zentralen Repository und alle Benutzer schicken Ihre Änderungen an dasselbe zentrale Repos. Das bedeutet das lokale Entwicklungen erst dann versionisiert werden, wenn sie ins zentrale Repository übermittelt werden. Git ermöglicht dagegen ein verteiltes System. Das bedeutet, fällt ein Repository aus, kann trotzdem nahtlos weitergearbeitet werden, da ein vollständiger Repository-Klon ein zwingender Vorgang ist. Git User sind damit nicht von einem funktionstüchtigen und immer erreichbaren zentralen Server abhängig.

Um ein eigenes Repository zu erstellen, erstellt man sich einfach ein Verzeichnis, öffnet es in der Konsole und führt
git init
aus. Möchte man dagegen eine Repository auschecken (z.B. von GitHub) führt man in dem Verzeichnis einfach folgenden Befehl aus
git clone url
oder, falls man Benutzerdaten (z.B. bei einer Firmeninternen Versionskontrolle) eingeben muss
git clone user@url
Das nun vorhandene lokale Repository besteht aus drei, von Git verwaltete, Ebenen:

• Arbeitsverzeichnis – Hier befinden sich die Dateien
• Index – hier sammelt Git alles was für den nächsten Commit ansteht
• Objektspeicher – Das lokale Repository. Hier speichert Git die Blobs (was die versionisierten Dateien sind) und die Trees (Die Zuordnung zwischen Datei/Pfad und einem Blob)

Jeder Commit, Tree oder Blob ist über eine ID eindeutig identifizierbar. Diese ID ist eine Prüfsumme, womit es unmöglich wird, dass Dateien oder Verzeichnisse sich ändern, ohne das Git es mitbekommt. Nehmen wir an wir haben drei Dateien geändert bzw. angelegt:

Wenn man sich nun eine Datei anlegt, oder eine vorhandene ändert, existiert diese Datei auf der Ebene des Arbeitsverzeichnis. Um diese dem Index, also der zweiten Ebene hinzuzufügen führ man folgenden Befehl aus:
git add datei
um eine bestimmte Datei dem Index hinzuzufügen, oder
git add .
um alle Änderungen dem Index hinzuzufügen. Um die Änderung nun an die dritte Ebene, dem Objektspeicher zu übergeben gibt man
git commit –m „Aussagekräftige Nachricht was geändert und warum“
ein. Nun befindet sich die Änderung im Objektspeicher. Bei einem weiteren Commit, der durch eine weitere Änderung erfolgt ist, verweist dieser auf den vorherigen. Damit wird eine Historie gebildet die wie folgt aussehen kann:

Jeder Commit bildet sozusagen einen eigenen Snapshot deines Arbeitsverzeichnises.
Nun möchte man seine Änderung ja noch in das entfernte Repository bringen, damit andere Entwickler sich diese herunterladen können.
git push origin master
erledigt das. „master“ ist der aktuelle Branch der mit dem initialen Commit erstellt wird, also der Standard Branch. Ein Branch ist nichts anderes als ein simpler Zeiger auf einen der Commits. Branches nutzt man um z.B. Funktionen voneinander unabhängig zu entwickeln.

Einen neuen Branch erstellt man mit
git branch featureX
Damit wird ein Zeiger auf den aktuellen Commit erstellt. Woher weiß Git nun, welchen Branch man aktuell verwendet. Dazu verwendet Git den Zeiger mit dem Namen „Head“. Head zeigt, anders wie bei SVN, immer auf den aktuellen lokalen Branch. Durch das Erstellen des Branch ist man also immer noch im master-Branch.
git checkout featureX
wechselt in den Branch „featureX“. Das Ganze, also Branch erstellen und sofort in diesen wechseln, geht auch in einen Schritt mit
git checkout –b
Um wieder in den master Branch zu wechseln, gibt man
git checkout
ein. Ein Branch wir mit
git branch –d
wieder gelöscht. Solange man den Branch mit
git push origin
nicht in das entfernte Repository hochgeladen hat, ist dieses nicht für andere verfügbar.
Möchte man nun sein lokales Repository mit den neusten Änderungen aktualisieren, verwendet man
git pull
Hier wird als erstes in deine Arbeitskopie die Änderungen heruntergeladen (fetch) und dann mit dem lokalen Stand zusammengeführt (merge). Möchte man nun die Änderungen aus einem Branch mit dem aktuellen Branch (z.B. master) zusammenführen, gibt man
git merge
ein. Git versucht in beiden Fällen, also bei pull und merge die Änderungen zusammenzuführen. Leider gelingt das nicht immer und es entstehen Konflikte. Diese müssen von Hand, z.B. durch das editieren einer Datei, vorgenommen werden. Moderne DIE’s unterstützen dabei allerdings auch Tatkräftig. Bevor man die Änderungen zusammenführt, kann man sich die Differezen auch mit
git diff
anschauen und dann wiederrum mit
git add .
zum Commit vorbereiten. Für den unwahrscheinlichen Fall das man etwas falsch macht, kann man mit
git checkout --
den letzten Stand zurücksetzen. Änderungen die man im Index gemacht hat, bleiben allerdings bestehen. Man kann lokale Änderungen auch komplett entfernen und sich den letzten Stand vom entfernten Repository holen:
git fetch origin
git reset –hard origin/master
Wie in anderen VCS kann Git auch bestimmte Punkte in der History als besonders wichtig kennzeichnen. Dieses Verfahren nennt man tagging. Dies wird in der Regel für Releases oder Hotfixes verwendet.
git tag
Zeigt einfach nur an, welche Tags vorhanden sind. In Git gibt es zwei Typen von Tags: einfache und kommentierte. Ein einfacher Tag ist wie ein Branch der sich nie ändert, also auch nur Zeiger auf einen bestimmten Commit. Kommentierte Tags werden jedoch als vollständiges Objekt in der Git Datenbank gespeichert. Das bedeutet sie haben eine Checksumme, einen Namen usw. Kommentierte Tags werden mit
git tag –a v1.2.3 –m „Version 1.2.3”
angelegt. Der Push Befehl lädt Tags nicht automatisch auf das externe Repository. Dies muss explizit passieren.
git push origin v1.2.3
lädt ein bestimmtes Tag hoch. Alle Tags, die dem externen Repository noch nicht bekannt sind, werden mit
git push origin --tags
hochgeladen. Jeder der das Repository nun klont, erhält automatisch alle Tags.
Ich hoffe ich konnte einen kleinen Einblick in Git möglich machen. Im nächsten Artikel steigen wir etwas tiefer ein und behandeln das Thema „Source Trees“ detailierter.