senäh

17senäh und so…

git_logo_img_only_140

Allgemein
27. Nov 2012
Kommentare: 0

Git für so halb-Fortgeschrittene

Kategorien: Allgemein | 27. Nov 2012 | Kommentare: 0

Serie: Versionskontrolle for the rest of us

Ihr habt brav die bisherigen Teile dieser Serie durchstöbert? Cool, dann seid ihr ja bereits mit den Grundlagen von Git vertraut. Darauf können wir aufbauen.

Stashing

Nicht selten arbeitet man an einem Feature, hat schon ein paar Zeilen Code geschrieben und bekommt plötzlich ein Ticket rein, das auf einen Bug in der laufenden Anwendung aufmerksam macht. Bugs haben Priotität, darum macht ihr euch schnell ran, den Bug zu fixen.

Doch eure Alarmglocken schlagen Alarm. Wir können doch nicht die bisherigen Änderungen für das neue Feature zusammen mit dem Bugfix comitten. Richtig. Also können tun wir das schon, nur ist das nicht besonders praktikabel. Unabhängig davon, dass ihr unfertige Features im Master hättet: Commits sollten immer eine sinnvolle Einheit bilden. So lässt sich die History besser nachverfolgen und ggf. rückgängig machen. Und darum geht’s ja in der Versionskontrolle.

Was machen wir also? Stashen. So bezeichnet man in Git den Vorgang aktuelle Änderungen zwischenzuspeichern, um sie anschließend ohne schlechtes Gewissen zu verwerfen – temporär versteht sich. Ein plötzlich notwendiger Bugfix ist das Paradebeispiel für den Einsatzzweck dieser Funktion.

Die Implementierung ist recht easy:

git stash

Die Änderungen werden in einem Kellerspeicher abgelegt, first-in-last-out. Hat man den Bug gefixed und will die Änderungen wiederhaben, benutzt man

git stash pop

So einfach ist das.

Hilfe, ich habe beim Commit etwas vergessen

Passiert mir allzu oft: ich committe 2, 3 Änderungen und beim nächsten Blick auf den Code fällt mir ein „Ach nee, da müssen noch 2 Kommentare raus.“ Kommt vor den Kollegen immer doof, für sowas einen extra Commit zu bemühen. Darum kann man einen Commit rückgängig machen:

git reset --soft HEAD^1

Der Parameter --soft sorgt dafür, dass die mit dem Commit gemachten Änderungen nicht verloren gehen, sondern direkt wieder gestaged werden. Git geht richtigerweise davon aus, dass wir die Änderungen nur ergänzen wollen. Das Konstrukt HEAD^1 gibt an, wie weit wir zurück wollen. Da wir nur den letzten Commit wollen, sagen wir „Ich will die Head-Revision minus 1 Commit.“

Also einfach die 2 Kommentare entfernen, Änderungen stagen, git commit und der Commit ist korrigiert.

Wichtig ist hierbei, dass ihr nur Commits ändert, die bisher lediglich lokal gemacht worden, also noch nicht zu GitHub o.ä. gesendet (gepusht) wurden.

Push und Pull

Wer bei der Vorstellung der Prinzipien hinter Git aufgepasst hat, weiß, dass Pull ein Update aus dem Repository holt und Push ein solches sendet (vgl.: Update/Commit bei SVN). Vor jedem Push ein Pull, bitte daran denken! Git wird euch zur Not drauf hinweisen ;)

Wenn ihr zum Testen ein (kostenloses) Repository bei GitHub anlegen möchtet, folgt einfach der Empfehlung vom letzten Mal und durchlauft TryGit. Ich hatte zwar angekündigt darauf einzugehen, jedoch könnte ich es nie besser machen als die CodeSchool-Mädels und -Jungs. Darum: hin da!

Nichtsdestotrotz noch etwas zu der Push- und Pullerei.

Pull

Ein Pull erfolgt so hier:

git pull origin master

git pull is der eigentlich Befehl, die beiden Wörter dahinter geben an, was genau gepullt werden soll. origin ist die Bezeichnung für das remote Repository. Der Name an sich ist willkürlich, ist aber ein Quasi-Standard. Es macht also Sinn diesen beizubehalten. master ist der Branch in diesem Remote Repository. Den Master als Branch zu bezeichnen, ist zwar unüblich, aber genau so ist es in Git. Auch der Master ist ein Branch.

Was wollen wir also machen: die Inhalte aus dem master Branch des Remote Repositories holen und mit dem lokalen Zustand abgleichen. Falls es Neuerungen gibt, die wir lokal noch nicht haben, werden diese entsprechend eingepflegt. Git erzeugt dabei u.U. automatisch einen Merge Commit, der den lokalen Fortschritt mit dem remote Fortschritt vereint.

Das wiederum lässt sich durch anhängen des Parameters –rebase umgehen. Dazu aber im nächsten Teil mehr, da die Sachlage hier etwas komplexer ist. Merken wir uns einfach, dass git pull —rebase gemütlicher ist. Und der faule Entwickler liebt gemütlich.

Push

Push ist also das Senden an das Remote Repository. Die Syntax dafür ist

git push origin master

Viel mehr gibt es dazu auch nicht zu sagen. Was es mit origin master auf sich hat, dürftet ihr schon wissen. Aber… eigentlich ist doch das ständige Angeben des Remote Branches überflüssig. Schließlich wollen wir Änderungen aus dem Branch holen, der dem Lokalen entsprichen, an dem wir gerade arbeiten. Selbiges gilt für das Pushen.

Gute Nachricht: insofern ihr eine aktuelle Version (=>1.8) von Git verwendet (kriegt ihr mit git —version heraus), könnt ihr beim Pullen den Remote Branch weglassen. Um das gleiche für git push zu erreichen, müsst ihr folgenden Befehl abfeuern:

git config --global push.default "current"

Das setzt voraus, dass eure lokalen Branches genauso heißen, wie die remote Branches (also der lokale master ist remote origin master, ein lokaler Branch namens cooles_feature heißt remote origin cooles_feature). Mehr Informationen dazu gibt’s hier.

Push und Pull nur bei cleanem Status

Die Push- und Pull-Kommandos werden nur ausgeführt, wenn euer Working Directory clean ist, d.h. ihr keine nicht comitteten Änderungen habt (doppelte Verneinungen FTW!!!). Falls dem so ist, wird Git die Ausführung verweigern. Abhilfe schafft an dieser Stelle git stash (siehe Anfang des Artikels).

Etwas mehr Farbe bitte

Wer im Terminal etwas Farbe haben möchte, wird für folgendes Kommando dankbar sein:

git config --global --add color.ui true

Das war’s… noch nicht ganz

Ein wichtiger Punkt fehlt noch: das Thema Branches. Da Branches eine Angelegenheit für sich sind und die Auseinandersetzung damit erst nach einiger Gewöhnung an die Git-Basics Sinn macht, werde ich noch einen Teil hinterherschieben.

Bis dahin dürft ihr die hier vermittelten Kenntnisse verinnerlichen und euch fragen: wird diese Serie zur Versionkontrolle je ein Ende finden? ;)

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 ;)

Kommentare (0)

Für diesen Beitrag wurden Kommentare deaktiviert.