senäh

17senäh und so…

Allgemein
17. Dez 2012
Kommentare: 3

Git und Branches

Kategorien: Allgemein | 17. Dez 2012 | Kommentare: 3

Serie: Versionskontrolle for the rest of us

Der vorerst letzte Teil der scheinbar endlosen Serie zur Versionskontrolle soll euch das Prinzip der Branches etwas näher bringen. Im Prinzip geht es darum, einen cleanen Entwicklungsstrang zu haben. Hier werden nur kritische Bug-Fixes getätigt, alles andere passiert in Branches, also Teilentwicklungssträngen (Danke, deutsche Sprache, für die umfangreichen Möglichkeiten der Wortzusammensetzung).

Neues Feature? Neuer Branch.
Unkritischer Bug-Fix? Neuer Branch.
Kleines Experiment? Neuer Branch.

Sobald die Änderungen aus einem Branch released bzw. deployed werden sollen, überführt man den Branch in den Hauptentwicklungsstrang (i.d.R. der Master- oder ein dedizierte Deploy-Branch). Das zumindest ist ein sinnvoller Ansatz um die Macht der Branches unter Git zu nutzen. Doch was ist mit den dazu passenden Kommandos?

Branch anlegen

Das anlegen eines Branches geschieht erstmal lokal über

git checkout -b mein_cooler_branch

Anschließend sollte im Terminal eine Meldung kommen wie

Switched to a new branch 'mein_cooler_branch'

Sobald ihr den Branch pusht, ist er auch im remote (ich benutze das hier mal kackfrech als eingedeutschtes Adjektiv) Repository vorhanden. Ich möchte an dieser Stelle noch mal daran erinnern, dass ihr über eine Änderung in der Git-Konfiguration erreichen könnt, dass git push auf den jeweils aktuellen Branch pusht, ohne dass ihr dessen Namen explizit angeben müsst.

git config --global push.default "current"

Statt git push origin mein_cooler_branch reicht in der Zukunft also git push. Awesomst.

Branches auflisten

Zusätzlich könnt ihr euch alle vorhanden Branches über git branch anzeigen lassen. Man beachte dabei:

git branch     # lokale Branches
git branch -r  # remote Branches
git branch -a  # alle Branches

Output für alle Branches sieht so hier aus:

  master
* mein_cooler_branch
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/origin/mein_cooler_branch

Zuerst werden die lokalen Branches aufgezählt (master und mein_cooler_branch). Der aktuelle Branch erhält ein Sternchen. Anschließend geht es um die entfernten Branches. Die HEAD-Revision, also die aktuellste Version des Repositories, wird einem Branch zugeordnet und die beiden anderen mit origin im Namen sind die remote Äquivalente zu den lokalen.

Falls ihr mal in die Situation kommt, die Zuordnung der lokalen zu den remote Branches wissen zu wollen, führt euch:

git remote show origin

zum Ziel.

Git aktuell halten!

Kurzer Hinweis: an dieser Stelle ist es wichtig, dass ihr die aktuelle Git-Version verwendet. In älteren Versionen musste man das automatische Tracking, also die Verbindung zwischen lokalem und remote Branch, noch selbst herstellen. Bei der Recherche haben zahlreiche Kommandos meinen Weg gekreuzt, die gar nicht mehr notwendig sind. Indem ihr also eine halbwegs aktuelle Version benutzt – ich habe zur Zeit die 1.8.0 – umgeht ihr viel Hassle.

Branches mergen

Ihr solltet eure Feature-Branches, also alles, was nicht Master bzw. Hauptentwicklungsstrang ist, immer wieder mit dem Master abgleichen. Den Vorgang nennt man Mergen.

git checkout mein_cooler_branch  # sicherstellen, dass wir im richtigen Branch sind
git pull origin master           # Änderungen aus dem Master-Branch holen

Alternativ könnt ihr auch in den Master wechseln, dort die letzten Änderungen pullen und diese dann in den Feature-Branch mergen.

git checkout master
git pull --rebase        # je nach Belieben mit oder ohne rebase
git checkout mein_cooler_branch
git merge master

Kon-Fucking-Flikte

Sollte sich dabei herauststellen, dass 2 Entwickler etwas an derselben Stelle geändert haben, so entstehen – wie bei Versionskontrollsystem üblich – Konflikte. Diese sind dadurch zu lösen, dass man die betroffene Datei bereinigt und sie anschließend staged (ihr erinnert euch: git add <Dateipfad>).

Die üblichen Konfliktmarker folgen dabei folgendem eventuell aus SVN geläufigen Muster:

    Text vor der Konfliktstelle.
<<<<<<< HEAD
    Das hier kommt von jemand anderem.
=======
    Das ist euer lokaler Stand.
>>>>>>> test
    Text nach der Konfliktstelle.

Ihr müsst euch also für eine von beiden Varianten entscheiden, den Rest (inklusive der Konfliktmarker) löschen und die Datei stagen um Git zu sagen, dass der Konflikt gelöst (resolved) wurde.

Im Zweifel könnt ihr euch immer an den Hinweisen orientieren, die Git auf der Kommandozeile gibt. In den meisten Fällen steht dort alles, was ihr wissen müsst, was Git angenehm n00b-sicher macht. Auch wenn beim Rebasing (git pull –rebase) Konflikte auftreten, könnt ihr euch einfach an den Git’schen Anweisungen entlang hangeln. Apropos…

Noch was zum Rebase

Ein Rebase sorgt dafür, dass Commit-Histories leichter zu lesen sind, indem die eigenen Änderungen so behandelt werden, als wären sie nach dem letzten Pull getätigt worden. Klingt komisch? Hier ist das im Abschnitt The mysterious & forever confusing ‘rebase’ ganz gut visualisiert.

Doch Obacht: es gibt Situationen, in denen man nicht rebasen sollte. Ich habe bis heute nicht wirklich verstanden, wie ich in eine solche Situation kommen soll und bin immer ganz gut mit rebase gefahren. Nichtsdestotrotz dürfen sich alle Interessenten hier informieren.

Die Bottom-Line ist dabei übrigens:

Don’t rebase branches you have shared with another developer.

Das ist meiner bescheidenen Auffassung nach so nicht ganz richtig, da ich z.B. den Master mit allen Entwicklern teile und trotzdem jedes Mal rebase.

Ich habe für mich folgende Regel beschlossen:

Wenn du Branches miteinander mergst, verzichte auf rebase.

Fahre damit wie gesagt ganz gut.

Wer hier Aufklärungsarbeit leisten kann, darf das gern tun 🙂

Ich habe fertig

Das war nun alles, was ich aus einem knappen halben Jahr Arbeit mit Git mitgenommen habe. Es gibt noch ein paar mehr Feinheiten, die man im Arbeitsalltag kennenlernt, aber ich will euch ja nicht komplett verwirren. Wer dennoch wichtige Hinweise hat, die dem senäh-Publikum nicht vorenthalten werden sollten, darf sie gern in die Kommentare posten. Ich selbst freue mich auch, wenn ich etwas dazulernen kann.

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