git ready

Push und Pull

Heute schauen wir ein weiteres mächtiges Grundkonzept an, das Git gegenüber anderen Versionskontrollsystemen besitzt: Verteilung! Wie du vielleicht weißt, sind deine Commits alle lokal und Repositories sind einfach nur Klone voneinandern. Die wirkliche Arbeit im Verteilen deines Projekts fällt beim Synchronisieren deiner Änderungen mit git push und git pull an.

Das sind viel zu hohe Unkosten die zu einem Zusammenbruch der Kontrolle führen, mag der Gitneuling vielleicht denken. Betrachte es auf diese Weise: Wenn dein Server ausfällt, wirst du meist daran gehindert weiter zu arbeiten und mit anderen zusammen zu arbeiten. Die tatsächliche Arbeit besteht im Erstellen von Revisionen auf deiner eigenen Maschine. Somit kannst du weiter programmieren, ob das Netzwerk nicht verfügbar ist oder sonstige Netzwerkprobleme bestehen. Habe ich schon erwähnt, dass Git bei Routineaufgaben um einiges Schneller ist? Weitere Vor- (und Nachteile) von DCVS gibt es auf Wikipedia.

Oliver Steele hat ein großartiges Bild zur Arbeitsweise von Push und Pull erstellt.

Der oberste Teil des Schaubilds ist einfach, deine Änderungen werden auf der staging area bereitgestellt. Sobald das erledigt ist, befindet sich deine Versionskontrolle am richtigen Platz, aber jetzt möchten wir es mit dem entfernten Repository abgleichen. Das kann ein Hoster wie GitHub sein, dein Git-Arbeitsserver, eine Produktiv-Maschine oder sogar das Repository eines Kollegen. Sobald die Änderungen ausgeliefert sind, können andere diese beziehen (pull) und mit ihnen arbeiten. Bei den meisten Aktionen in Git gibt es ein paar Optionen, aber heute bleiben wir bei pull.

Wir gehen durch ein reales Beispiel. Ich habe den Twitter Link am Fuß dieses Blogs eingefügt. Ich möchte die Änderungen zum Projekt-Repository auf GitHub übertragen (push), um den Server zu aktualisieren. Die Syntax für das Kommando lautet git push <remote> <branch>. ist hauptsächlich die Adresse des geklonten Repositorys. Es enthält so ziemlich genau die selben Daten und Historien und wartet darauf aktualisiert zu werden. Die meisten Repositorys arbeiten gewöhnlich mit einer Gegenstelle namens origin und dem Branch master.

$ git commit -am "Adding twitter link"
  Created commit f2cd831: Adding twitter link
  1 files changed, 1 insertions(+), 0 deletions(-)

$ git push origin master
  Counting objects: 7, done.
  Compressing objects: 100% (4/4), done.
  Writing objects: 100% (4/4), 407 bytes, done.
  Total 4 (delta 2), reused 0 (delta 0)
  To git@github.com:qrush/gitready.git
     361303d..f2cd831  master -> master

Jetzt, wo das entfernte Repository, die Gegenstelle, aktualisiert ist und wenn du auf GitHub vorbei schaust, kannst du die Commits sehen. Die Kommandoausgabe gibt an, wie Git die geänderten Datenblobs überträgt und läßt uns wissen, dass das Repository aktualisiert ist, indem es den geänderten SHA1-Hash zeigt.

Aber was ist mit pull? Wir können es zum Abgleich der soeben gemachten Commits mit jeglichen Repositories verwenden. Das Projekt-Deployment Script macht genau das:

$ git pull origin master
  remote: Counting objects: 7, done.
  remote: Compressing objects: 100% (4/4), done.
  remote: Total 4 (delta 2), reused 0 (delta 0)
  Updating 361303d..f2cd831
  Fast forward
   _layouts/default.html |    1 +
    1 files changed, 1 insertions(+), 0 deletions(-)

Die Ausgabe zeigt uns, dass das Repository auf dem Server ein paar Änderungen vom entfernten Repository einholen muss und holt diese sogleich ab. Der Prozess wäre exakt derselbe, wenn du Bereitstellungen einer anderen Person in dein Repository einbringen wolltest. Jene, die das Gitready Repository auf GitHub abgespaltet haben, können nun meine vorgenommenen Änderungen abholen. Zukünftige Tutorien behandeln diesen Prozess in größere Detailtiefe.

Wenn dir andere Ideen oder Konzepte einfallen, die hier vergessen wurden, lass es uns bitte wissen.