senäh

17senäh und so…

Allgemein
22. Okt 2012
Kommentare: 2

Git für SVN-Umsteiger

Kategorien: Allgemein | 22. Okt 2012 | Kommentare: 2

Serie: Versionskontrolle for the rest of us

Als ich gerade halbwegs warm mit SVN wurde, hörte ich von allen Ecken, dass Git der neue heiße Scheiß sei. Schon wieder was neues. Dabei wirkte Git von Anfang an irgendwie cooler als SVN. Mehr Nerd als Geek. Git zu SVN wie Ruby zu Java oder so. Von Berufswegen hatte ich endlich ein Projekt, bei dem ich mich mit Git auseinandersetzen musste, so dass ich euch hier demonstrieren kann, was dabei so hängen geblieben ist.

Kein zentrales Repository mehr… eigentlich

Das Grundprinzip ist an sich identisch. Obowhl… im nächsten Schritt eigentlich überhaupt nicht. Aber eins nach dem anderen.

Der Hauptunterschied zwischen SVN und Git ist, dass es nicht wie bei SVN ein zentrales Repository gibt. Jeder Entwickler hat seine eigene Kopie. Und jede einzelne davon könnte eigentlich das Zentrale darstellen. Im produktiven Workflow macht ein zentraler Git-Server natürlich Sinn. Nichtsdestotrotz ist dieser Unterschied wichtig, um ein paar Feinheiten bei Git zu verstehen und schätzen zu lernen.

Der eigentliche Workflow basiert weiterhin auf dem lokalen Entwickeln und dem Weiterleiten der Änderungen an den Rest des Dev-Teams. Die Werkzeuge dafür sind ebenfalls Commits und Updates, allerdings nicht in der SVN-Form. Update heißt z.B. pull, aber auch semantisch gibt es einige Unterschiede.

Vor dem Commit ist nach dem Commit

Der Commit in SVN-Form wird bei Git in 3 Stufen unterteilt:

  • Staging
  • Commit
  • Push

Stagen (oder adden) ist gleichzusetzen mit dem Aktivieren von Haken im SVN-Client, um zu bestimmen, welche Dateien committet werden sollen. Mehr nicht. Welche Vorteile das hat? Etwas Geduld bitte, Beispiele folgen noch 🙂

Das, was in Git als Commit betitelt wird, ist das committen der Änderungen in das lokale Repository. Die Änderungen sind angewendet und werden deshalb anschließend in der Änderungsliste nicht mehr angezeigt. Halt wie ein Commit bei SVN mit dem Unterschied, dass der neue Code nicht direkt im zentralen sondern in eurem lokalen Repository landet.

Ein Push ist dann der letzte Schritt, also das Senden zum zentralen Repository, z.B. bei GitHub. Dieser Schritt erscheint manchmal überflüssig. Mir hilft er aber immer dann, wenn ich nach einem Commit feststelle, dass ich doch noch einen Kommentar im Code vergessen habe, der gelöscht werden sollte. Dadurch, dass die Änderungen noch nicht im zentralen Repository waren, kann ich den Commit im Nachhinein noch verändern.

git stash – nützlicher Zwischenspeicher

Was ich wirklich zu schätzen gelernt habe, ist die Möglichkeit Änderungen zu stashen, d.h. in einen Zwischenspeicher auszulagern. Die entsprechenden Änderungen werden rückgängig gemacht, dabei aber zwischengespeichert, um sie später wieder anwenden zu können. 2 sinnvolle Einsatzgebiete dafür gibt es in den Beispielen.

Das Prinzip hinter Git – ennovativ visualisiert 😉

Für einen Neuling klingt Git erstmal wesentlich komplexer als SVN. Vielleicht ist das auch so. Allerdings sind die Ebenen in Git viel näher an der Arbeitsweise eines Entwicklers, weswegen die Routinen recht schnell in Fleisch und Blut übergehen.

In einem Versuch diese Aussage zu verdeutlichen ist folgendes Schema entstanden:

Git-Schema

Git-Schema

Ein paar kleine Anmerkungen dazu:

  • Alles Grüne sind Git-Befehle, der Rest bestimmte Stationen im Workflow. Gehen 2 Pfeile von einem Befehl oder eine Stations weg, deutet dies auf optionale Wege hin. Es können 2 Wege gegangen werden, müssen aber nicht.
  • HEAD Revision beschreibt die aktuellste Version.
  • Das Holen der Änderungen aus dem Zwischenspeicher wird durch den gestrichelten Pfeil in Richtung Änderungen visualisiert.

Bei Fragen, Änderungen, Verbesserungen zum Schema: einfach ab in die Kommentare damit 🙂

Next Up: Beispiele

Um euch ausnahmsweise mal nicht mit einem tl;dr-Kandidaten zu überfluten folgt der zweite Teil zu Git (und damit der vierte Teil der Serie) in der kommenden Woche. Darin wird es um die konkreten Schritte beim Arbeiten mit Git gehen. Bis dahin dürft ihr das oben dargestellte Schema gern verinnerlichen 🙂

Autor: Enno

Ich bin Enno. PHP ist mein Ding, aber auch alles Neue rund um die Themen HTML5, CSS3 & Co finde ich interessant. Ich mag es Leuten zu helfen und mein Wissen weiterzugeben. Sollte dir mein Beitrag gefallen haben, lass doch nen Kommentar da oder benutze einen der Social Buttons, um deinen Dank auszudrücken ;)