Strom sparender Computereinsatz hilft nicht zuletzt auch Kosten zu senken. ADMIN 02/2011 geht der Frage nach, was Administratoren tun können, damit ihre ... (mehr)

Abzweigen

Git ist enorm flexibel, und die Möglichkeiten zur Verzweigung (branches) und Zusammenführung (merge) sind nahezu unbegrenzt. Abzweigen (das Erstellen mehrerer "Kopien" vom gleichen Repository) bedeutet, dass Sie eine Reihe von Änderungen zeitweilig abtrennen, während Sie mit ihnen experimentieren, oder dass Sie verschiedene Versionen eines Projekts erstellen, um den Baum nicht zu beeinträchtigen. Das Abzweigen in Git ist schnell und einfach, und es ist ebenso einfach, wieder alles in den Baum zurückzuführen. Arbeiten Sie also nach Möglichkeit zunächst in einem separaten Branch. Die grundlegenden Git-Befehle für Branches sind:

  • »git branch« listet die aktuellen Zweige des Projekts auf.
  • »git branch Name« erzeugt einen neuen, lokalen Zweig.
  • »git branch -d Name« löscht den entsprechenden Zweig.
  • »git checkout Name« wechselt in den lokalen Zweig über. Verwenden Sie »git checkout -b Name« , um den Zweig auch gleich zu erstellen, wenn Sie darin wechseln.

Nehmen wir an, Sie wollen einen neuen Zweig für Ihr Projekt erstellen und diesen V1.5 benennen. Zunächst erstellen Sie den neuen Zweig: »git branch V1.5« . Ihr Repository hat nun zwei Zweige, aber das aktuelle Verzeichnis entspricht immer noch dem Master (dem Hauptzweig, der automatisch "Master" heißt). Der Befehl »git branch« zeigt Ihnen das an: Alle bestehenden Zweige sind aufgelistet, und vor dem aktuellen Arbeitszweig steht ein Stern ( Abbildung 3 ).

Abbildung 3: Einen lokalen Zweig erzeugen und in den lokalen Zweig wechseln (beachten Sie den Zweignamen am Anfang der Status-Ausgabe).

Sie wechseln nun mit »git checkout V1.5« in Ihren neuen, lokalen Zweig. In der Ausgabe von »git status« erscheint nun dieser Zweig mit dem Stern davor. Nun arbeiten Sie in diesem Zweig. Führen Sie die gewünschten Änderungen durch und übertragen (committen) Sie diese wie üblich. Zum Master wechseln Sie wieder mit »git checkout master« zurück. Ihre Änderungen werden hier nicht sichtbar sein. Wechseln Sie wieder zum Zweig V1.5, und da sind sie wieder.

Zusammenführen

Um Zweige wieder zusammenzuführen, verwenden Sie »git merge Name « . Dies wird den Branch »Name« in den aktuellen Zweig (in das aktuelle Arbeitsverzeichnis) einfädeln.

In unserem Beispiel wechseln Sie also zunächst zum Master mit ( »git checkout master« ), dann führen Sie die Änderungen vom Zweig V1.5 mit »git merge V1.5« in den Master hinein. Der Zweig V1.5 und der Master sind nun zwar identisch, aber »git status« zeigt, dass der zusätzliche Zweig immer noch existiert. Wechseln Sie nun wieder in den Zweig V1.5, um Ihre Entwicklungsarbeit weiterzumachen!

Beachten Sie, dass Git keinen Merge-Vorgang zulässt, solange es noch nicht übertragene Änderungen gibt, da beim Merge das bestehende Arbeitsverzeichnis überschrieben wird. (Als Workaround eignet sich in einem solchen Fall »git stash« – siehe weiter unten in diesem Artikel.)

Das Zusammenfügen von Dateien erledigt Git beim Merge so gut wie möglich automatisch. Aber manchmal gibt es Konflikte (Änderungen, die einander gegenseitig beeinflussen). In einem solchen Fall wird der Merge scheitern, und Git zeigt eine Warnung mit den problematischen Dateien an. Auch »git status« führt diese Dateien als nicht zusammengeführt auf. Öffnen Sie dann die problematischen Dateien in einem Texteditor, um den Konflikt selbst aufzulösen. Die entsprechenden Abschnitte werden gekennzeichnet, wie in Listing 3 .

Listing 3

Konflikt

 

Beide Versionen der Datei werden angezeigt, und Sie entscheiden, wie Sie das Problem lösen. Sobald Sie mit der Korrektur der Dateien fertig sind, führen Sie »git add Dateiname « bei allen problematischen Dateien aus, dann vollenden Sie den Merge mit »git commit« . Alternativ können Sie auch »git commit -a« verwenden, um alle Konflikte als gelöst zu markieren. Achten Sie darauf, dass diese wirklich aufgehoben wurden, bevor Sie das tun!

Arbeiten Sie im Team, dann gibt es mehrere Möglichkeiten, um die eigenen Änderungen den anderen Mitgliedern bereitzustellen. Die übliche Vorgehensweise besteht darin, einen Patch zu erzeugen (eine Textdatei, die Ihre Änderungen gegenüber dem Projekt-Baum beschreibt) und diesen per E-Mail zu verschicken. Glücklicherweise macht das Git-Patching-System diese Sache sehr einfach.

Bevor Sie überhaupt mit irgendwelchen Änderungen anfangen, sollten Sie zuerst einen neuen Zweig anlegen:

git checkout -b MyBugFix

Von nun an arbeiten Sie im Zweig »MyBugFix« weiter. (Lesen Sie die Informationen zum Befehl »git stash« weiter unten in diesem Artikel, falls Sie die Arbeit bereits am Master-Zweig begonnen haben.) Nachdem Sie Ihre Änderungen vollbracht und ins lokale Git-Repo übertragen haben, müssen Sie zunächst sicherstellen, dass Ihr lokales Repository auf dem neuesten Stand ist. Sonst würden Sie einen Patch erstellen, der sich auf eine veraltete Version bezieht. Wechseln Sie dazu mit »git checkout master« zurück in den Master-Zweig und aktualisieren Sie diesen mit »git pull« aus dem ursprünglichen Repository.

Wechseln Sie nun wieder mit »git checkout MyBugFix« zu Ihrem Arbeitszweig über, und geben Sie hier den Befehl »git rebase master« ein. Damit übernehmen Sie die Master-Änderungen in Ihren »MyBugFix« Arbeitszweig. (Selbstverständlich müssen Sie die eventuellen Konflikte ebenfalls aufheben.) Git frischt die Versionsgeschichte auf und Ihr Zweig stammt nun von der allerjüngsten Version des Masters ab: ideale Voraussetzungen, um einen Patch zu erstellen:

git format-patch master --stdout > mybugfix-patch.diff

Dadurch wird der aktuelle Arbeitszweig (hier »MyBugFix« ) mit dem Master-Zweig verglichen, und jeder Commit ausgefiltert, der im Master-Zweig nicht vorhanden ist. Je nach Commit wird ein Patch auf stdout ausgegeben und dann in die Datei »mybugfix-patch.diff« weitergeleitet. Alternativ verwenden Sie »git format-patch master« , um im aktuellen Arbeitsverzeichnis einen Patch pro Commit zu generieren oder »git format-patch master -o patchdir« , um diese im Patch-Verzeichnis abzulegen. Die einzelnen Patches sehen wie eine E-Mail aus.

Einen Patch von jemand anderem wenden Sie mit »git am« an. Zunächst erstellen Sie dazu einen neuen Zweig mit »git checkout -b SarahsPatch« , um den Patch nicht mit eigenen Änderungen zu verwechseln. (Es ist mit Git sehr einfach Zweige zu erstellen und diese wieder zusammenzuführen, nutzen Sie also dieses Feature!) Dann führen Sie die Änderungen mit »git am sarahspatchfile.diff« zusammen, um den Überblick zu haben.

Bei extern verwalteten Projekten möchten Sie wahrscheinlich nicht gleich alle Änderungen in Ihren Master-Zweig einfügen, sondern warten lieber bis diese zentral anerkannt wurden (also bis zum nächsten Update mit »git pull« ). Geht es aber um ein kleines Projekt, in dem nur Sarah und Sie beteiligt sind, und sind Sie mit diesem Patch zufrieden, dann führen Sie diesen Zweig mit »git checkout master; git merge SarahsPatch« in den Master-Zweig über.

Beachten Sie, dass »git am« auch mit Patch-Dateien umgehen kann, die in einer E-Mail angekommen sind. Schmeißen Sie dazu einfach all Ihre Patches in eine Mailbox (im Linux Mailbox-Format) und geben Sie dann den Befehl »git am mailboxfile« ein. Der Autorname wird dabei aus der »From:« -Zeile, das Datum aus der »Date:« -Zeile, und die Benennung aus der »Subject:« -Zeile der E-Mail übernommen. Die Beschreibung übernimmt Git aus der »Subject:« -Zeile und dem Text des E-Mail-Body bis zum Beginn des eigentlichen Patches. Dieses Format benutzt Git auch beim Speichern eines Patches mit »git format-patch« .

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023