logo-gitEine große Stärke von Git kam bisher noch gar nicht zur Sprache: Die Möglichkeit, Projekte über GitHub zu teilen. GitHub ist eine Plattform, auf der man Projekte öffentlich zur Verfügung stellt. Die Idee dahinter ist, dass man so im Team arbeiten kann. Viele OpenSource-Projekte wohnen deshalb auf GitHub. 

Wir entwickeln Themes für Kundenprojekte, als Grundlage benutzen wir dazu das _s-Theme von Automattic. Freundlicherweise gibt’s das auf GitHub. Den Code zu kopieren ist nicht so ein großes Problem, aber wir möchten möglichst effizient damit arbeiten. Das bedeutet, wir wollen nicht nur eine Kopie haben, wir wollen auch keine Updates von Automattic verpassen. Wie geht das?

Fork

Zunächst einmal richte ich mir einen Account bei GitHub ein. Dann suche ich auf GitHub nach „_s“. Auf der _s-Seite von Automattic angekommen, kann ich mir alle Dateien anschauen, sehen, wer alles beigetragen hat, was die letzten Änderungen waren und so weiter.

Wenn ich selbst mit dem Theme arbeiten möchte, klicke ich auf den „Fork“-Button rechts oben auf der Seite. Das Icon erinnert an eine Gabel, und es steht FORK drauf. Sobald ich das angeklickt habe, legt GitHub in meinem Account ein öffentliches Verzeichnis namens „_s“ an. Dort könnte ich jetzt loslegen, aber ich möchte in meiner lokalen Entwicklungsumgebung arbeiten. Dafür muss ich noch etwas anderes tun.

Clone

Eine 1:1 Kopie heißt in der Sprache von Git „Clone“. Ich möchte also einen Clone vom _s-Theme in meinem lokalen System haben.
Zuerst muss ich mir überlegen, in welchem Verzeichnis der Clone auf meinem lokalen Rechner liegen soll. Ich bewege mich im Terminal durch die Verzeichnisse an den richtigen Ort und gebe folgenden Code ein:

$ git clone https://github.com/username/_s.git

Damit wurde im Verzeichnis, das ich ausgewählt habe, ein Verzeichnis namens „_s“ angelegt. Einmal ins Verzeichnis reingehen und prüfen: Es sollten alle Dateien aus dem GitHub-Repository vorhanden sein.

$ ls -la

Der Befehl zeigt mir auch die versteckten Verzeichnisse, in diesem Fall das .git Verzeichnis.

Ein so geclontes Repository enthält alle Informationen des Original-Repository. Es könnte im Notfall dessen Platz einnehmen und es würde kein Unterschied zu sehen sein.

Verknüpfen mit dem Original _s

Mein lokales Git weiß, dass mein lokales Verzeichnis „_s“ ein Clone meines _s-Repositories auf GitHub ist. Es weiß aber nicht, dass das Repository wiederum ein Fork von Automattic ist. Als „Remote“, also entferntes (im Sinne von nicht lokales) Verzeichnis gibt es im Moment nur „Origin“, das ist das Verzeichnis in meinem Account auf GitHub.

Genauso wie beim Initialisieren von Git automatisch der „Master“-Branch angelegt wird, wird beim Clonen automatisch „Origin“ als Remote angelegt.
Wie bei den Branches kann ich auch weitere Remotes hinzufügen.

Wenn ich mein lokales _s-Repository mit dem bei Automattic vergleichen möchte, muss ich das _s-Repository von Automattic als Remote angeben. Dazu suche ich mir auf GitHub die korrekte URL und gebe folgenden Befehl ein:

$ git remote add automattic https://github.com/Automattic/_s

Achtung: Ich habe mein Remote „automattic“ genannt. Das könnte auch „Christbaumkugel“ heißen oder „Osterhase“, Hauptsache Ihr wisst nachher noch, was damit gemeint ist.
Jetzt ist alles so eingerichtet, dass ich jederzeit meine Kopie von _s mit dem Original auf GitHub vergleichen kann.

Änderungen des Originals von GitHub holen

Angenommen, ich habe nun eine Weile auf der Basis des Starterthemes _s an meinem Theme gearbeitet. Da die Entwicklungen auf GitHub schnell vorangehen, sollte ich mal prüfen, was inzwischen passiert ist. Da ich oben „automattic“ als Remote angelegt habe, brauche ich jetzt die URL nicht auswendig zu wissen. Um die neuesten Änderungen von _s zu bekommen, gebe ich ein:

$ git fetch automattic

Das bedeutet, dass ich erst einmal die Änderungen lade, sie aber noch nicht in meinen Master-Branch übernehme. Ich bekomme folgende Rückmeldung:

$ git fetch automattic
remote: Counting objects: 10, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 6 (delta 4), reused 5 (delta 3)
Unpacking objects: 100% (6/6), done.
From https://github.com/Automattic/_s
54614ee..2927f7c master -> automattic/master

Ich kann nun per Befehl

$ git checkout automattic/master

in automattic/master wechseln und mir die Änderungen anschauen.

Änderungen in mein Projekt übernehmen

Ich kann aber auch einen Merge durchführen. Dazu muss ich aber erst in meinen Master-Branch wechseln.

$ git checkout master
$ git merge automattic/master

Eventuelle Merge-Konflikte zeigt mir Git an. Dabei versucht Git, so viele Konflikte wie möglich automatisch zu lösen. Nur wenn Änderungen desselben Codes stattgefunden haben, muss ich den Konflikt von Hand auflösen. Git markiert die Stellen, so dass es immer noch recht komfortabel ist.

Im nächsten Artikel wird es darum gehen, wie Ihr Unterschiede zwischen mehreren Versionen sichtbar machen könnt und wie man Änderungen wieder rückgängig macht.