9.1 Git und andere VCS-Systeme - Git als Client

Der Hauptbefehl in Git für sämtliches Subversion-Bridging ist git svn. Es sind ziemlich wenige Befehle erforderlich, so dass wir die gängigsten aufzeigen und dabei einige einfache Workflows durchgehen werden.

Es ist wichtig zu beachten, dass du bei der Verwendung von git svn mit Subversion interagierst. SVN ist ein System, das ganz anders funktioniert als Git. Obwohl du lokales Branching und Merging durchführen kannst, ist es im Allgemeinen ratsam, deinen Verlauf so linear wie möglich zu gestalten, indem du deine Arbeiten rebased. Vermeide dabei die gleichzeitige Interaktion mit einem Git Remote-Repository.

Schreibe deinen Verlauf nicht um und versuche nicht, diesen geänderten Verlauf erneut zu pushen. Pushe nicht in ein paralleles Git-Repository, um gleichzeitig mit anderen Git-Entwicklern zusammenzuarbeiten. Subversion kann nur einen einzigen linearen Verlauf haben und es ist sehr einfach, diesen Verlauf durcheinanderzubringen. Wenn du mit einem Team arbeitest und einige verwenden SVN und andere Git, stelle sicher, dass alle den SVN-Server für die gemeinsame Arbeit verwenden – das erleichtert dir deinen Alltag.

Um diese Funktionalität zu demonstrieren, benötigst du ein SVN-Repository mit Schreibzugriff. Wenn du die Beispiele kopieren möchtest, musst du eine beschreibbare Kopie eines SVN-Test Repository erstellen. Um das zu tun, kannst du das Tool svnsync verwenden, das in einer Subversion-Installation enthalten ist.

Um dem Beispielen zu folgen, musst du zunächst ein neues lokales Subversion-Repository erstellen:

Aktiviere dann alle Benutzer, um revprops zu ändern. Der einfachste Weg ist, ein pre-revprop-change Skript hinzuzufügen, das immer den exit-Wert 0 hat:

Du kannst dieses Projekt nun auf deinem lokalen Rechner synchronisieren, indem du svnsync init mit den Repositorys to und from aufrufst.

Dadurch werden die Eigenschaften für die Ausführung der Synchronisierung festgelegt. Anschliessend kannst du den Code klonen, indem du Folgendes ausführst:

Obwohl dieser Vorgang nur wenige Minuten in Anspruch nehmen könnte, dauert der Prozess fast eine Stunde, wenn du versuchen solltest, das ursprüngliche Repository in ein anderes Remote-Repository anstelle eines lokalen zu kopieren, obwohl es weniger als 100 Commits gibt. Subversion muss eine Revision nach der anderen klonen und sie dann wieder in ein anderes Repository verschieben. Es ist äußerst ineffizient, aber es ist der einzige einfache Weg, das zu erreichen.

Jetzt, da du ein beschreibbares Subversion-Repository hast, kannst du einen normalen Workflow nutzen. Beginne mit dem Befehl git svn clone, der ein komplettes Subversion-Repository in ein lokales Git-Repository importiert. Beachte, dass du beim Import aus einem echten Subversion-Repository file:///tmp/test-svn durch die URL deines Subversion-Repositorys ersetzen musst:

Das entspricht zwei Befehlen – git svn init gefolgt von git svn fetch – auf der von dir angegebenen URL. Dieser Vorgang kann einige Zeit dauern. Wenn beispielsweise das Testprojekt nur etwa 75 Commits hat und die Code-Basis nicht so groß ist, muss Git dennoch jede Version einzeln auschecken und einzeln committen. Bei einem Projekt mit Hunderten oder Tausenden von Commits kann es Stunden oder gar Tage dauern.

Der Teil -T trunk -b branches -t tags teilt Git mit, dass dieses Subversion-Repository den grundlegenden Branching- und Tagging-Konventionen folgt. Wenn du deinen Trunk, deine Branches oder Tags anders benennst, können sich diese Optionen ändern. Da dies so häufig vorkommt, kannst du den gesamten Teil durch -s ersetzen, was Standardlayout bedeutet und all diese Optionen beinhaltet. Das folgende Kommando ist dabei gleichwertig:

An dieser Stelle solltest du über ein valides Git-Repository verfügen, das deine Branches und Tags importiert hat:

Beachte, dass dieses Tool Subversion-Tags als Remote-Referenzen (engl. refs) verwaltet. Werfen wir einen genaueren Blick auf den Git Low-Level-Befehl show-ref:

Git macht das nicht, wenn man von einem Git-Server geklont hat. So sieht ein Repository mit Tags nach einem frischen Klon aus:

Git fetched die Tags direkt in refs/tags, anstatt sie mit entfernten Branches zu verknüpfen.

Jetzt, da du ein Arbeitsverzeichnis hast, kannst du an dem Projekt arbeiten und deine Commits wieder zum Upstream pushen, indem du Git als SVN-Client verwendest. Wenn du eine der Dateien bearbeitest und überträgst, hast du einen Commit, der in Git lokal existiert aber nicht auf dem Subversion-Server vorhanden ist:

Als nächstes musst du deine Änderung zum Upstream pushen. Beachte, wie sich dies auf deine Arbeitsweise mit Subversion auswirkt. Du kannst mehrere Commits offline durchführen und diese dann alle auf einmal auf den Subversion-Server übertragen. Um zu einem Subversion-Server zu pushen, führe den Befehl git svn dcommit aus:

Dies erstellt für jeden Commit, den du auf deinem Subversion Server-Codes gemacht hast, einen eigenen Subversion-Commit und schreibt deinen lokalen Git-Commit um, um einen eindeutigen Identifier einzufügen. Das ist wichtig, weil es bedeutet, dass sich alle SHA-1-Prüfsummen für deine Commits ändern. Aus diesem Grund ist es keine gute Idee, gleichzeitig mit Git-basierten Remotes deines Projekts und einem Subversion-Server zu arbeiten. Wenn du dir den letzten Commit ansiehst, siehst du die neu hinzugefügte git-svn-id:

Es ist zu beachten, dass die SHA-1-Prüfsumme, die ursprünglich mit 4af61fd begann, als du die Daten übertragen hast, nun mit 95e0222 beginnt. Wenn du sowohl auf einen Git-Server als auch auf einen Subversion-Server pushen möchtest, musst du zuerst auf den Subversion-Server pushen (dcommit), da diese Aktion deine Commit-Daten ändert.

Wenn du mit anderen Entwicklern zusammenarbeitest, wird irgendwann einer von euch pushen, und andere versuchen, eine Änderung voranzutreiben, die Konflikte verursacht. Diese Änderung wird abgelehnt, bis du deren Arbeit mergst. In git svn sieht das so aus:

Um diese Situation zu lösen, kannst du git svn rebase ausführen, das alle Änderungen auf dem Server, die du noch nicht hast, pullt und alle deine lokalen Arbeiten auf den gepullten Code rebased:

Jetzt ist deine gesamte Arbeit auf den Code des Subversion-Servers rebased, so dass du dcommit erfolgreich einsetzen kannst:

Im Unterschied zu Git, das voraussetzt, dass du Upstream-Arbeiten, die du noch nicht lokal hast, zuerst mergst, bevor du pushen kannst, zwingt dich git svn dazu nur dann, wenn die Änderungen im Konflikt stehen (ähnlich wie bei Subversion). Wenn jemand anderes eine Änderung an einer Datei macht und du eine Änderung an einer anderen Datei machst, funktioniert dein dcommit gut:

Es ist sehr wichtig, sich daran zu halten, denn das Ergebnis ist ein Projektstatus, der beim Push auf keinem deiner Computer vorhanden war. Wenn die Änderungen inkompatibel sind, aber keine Konflikte verursachen, können Probleme auftreten, die schwer zu diagnostizieren sind. Das ist ein Unterschied gegenüber der Nutzung eines Git-Servers. In Git kannst du den Zustand auf deinem Client-System vor der Veröffentlichung vollständig testen, während du in SVN nie sicher sein kannst, dass die Zustände unmittelbar vor dem Commit und nach dem Commit identisch sind.

Du solltest diesen Befehl auch ausführen, um Änderungen vom Subversion-Server einzubinden, auch wenn du noch nicht bereit bist, selbst zu committen. Es ist ratsam, git svn fetch auszuführen, um die neuen Daten zu holen, aber git svn rebase übernimmt bereits den Fetch und aktualisiert dann deine lokalen Commits.

Wenn du ab und zu git svn rebase laufen lässt, stellst du sicher, dass dein Code immer auf dem neuesten Stand ist. Du solltest jedoch überprüfen, ob dein Arbeitsverzeichnis sauber ist, wenn du diese Funktion ausführst. Wenn du lokale Änderungen hast, musst du deine Arbeit entweder verstecken (engl. stash) oder temporär committen, bevor du git svn rebase ausführst. Andernfalls wird der Befehl angehalten, wenn er erkennt, dass das Rebase zu einem Merge-Konflikt führen wird.

Sobald du dich mit einem Git-Workflow vertraut gemacht hast, wirst du wahrscheinlich Topic-Branches erstellen, an ihnen arbeiten und sie dann mergen wollen. Wenn du über git svn auf einen Subversion-Server pushst, kannst du deine Arbeit jedes Mal auf einen einzigen Branch rebasen, anstatt Branches zu mergen. Die Begründung für ein Rebasing ist, dass Subversion eine lineare Historie hat und sich nicht wie Git mit Merges beschäftigt. So folgt git svn bei der Konvertierung der Snapshots in Subversion Commits nur dem ersten Elternteil.

Nehmen wir an, dein Verlauf sieht wie folgt aus: Du hast einen experiment Branch erstellt, zwei Commits durchgeführt und diese dann wieder mit dem master zusammengeführt. Wenn du dcommit aufrufst, erscheint folgende Anzeige:

Das Ausführen von dcommit auf einem Branch mit zusammengeführtem Verlauf funktioniert gut, außer wenn du dir dein Git-Projekt-Historie ansiehst. Es wurde keiner der Commits, die du auf dem experiment Branch gemacht hast, neu geschrieben – statt dessen erscheinen alle diese Änderungen in der SVN-Version eines einzelnen Merge-Commits.

Wenn jemand anderes diese Arbeit klont, sieht man nur den Merge-Commit mit der gesamten Arbeit, die in ihn zusammengeführt wurde, als ob du git merge --squash ausgeführt hättest. Man sieht die Commit-Daten nicht, weder woher sie stammen noch wann sie committed wurden.

Branching in Subversion ist nicht dasselbe wie Branching in Git. Es ist wahrscheinlich das Beste, wenn du es so gut es geht vermeidest. Du kannst aber mit git svn in Subversion Branches anlegen und dorthin committen.

Um einen neuen Branch in Subversion zu erstellen, führe git svn branch [new-branch] aus:

Dadurch wird das Äquivalent des Befehls svn copy trunk branches/opera in Subversion ausgeführt und auf dem Subversion-Server angewendet. Es ist wichtig zu beachten, dass dieser Branch nicht ausgecheckt wird. Wenn du an diesem Punkt einen Commit durchführst, geht dieser Commit in den trunk auf dem Server, nicht in opera.

Git findet heraus, in welchen Branch deine dcommits hingehen, indem es nach dem Ende eines deiner Subversion Branches in deinem Verlauf sucht – du solltest nur einen haben, und es sollte der Letzte sein, der eine git-svn-id in deinem aktuellen Branchverlauf hat.

Wenn du an mehr als einem Branch gleichzeitig arbeiten möchtest, kannst du lokale Branches so einrichten, dass du dcommit für bestimmte Subversion-Branches ausführst, indem du diese beim importierten Subversion-Commit für diesen Branch startest. Einen opera Branch, mit dem du separat arbeiten kannst, kannst du folgendermaßen initialisieren:

Um deinen opera Branch in trunk (deinen master Branch) zu mergen, kannst du das mit einem normalen git merge machen. Aber du solltest unbedingt eine beschreibende Commit-Meldung (via -m) angeben, sonst wird beim Merge anstelle von etwas Vernünftigem „Merge branch opera“ angezeigt.

Obwohl du für diese Operation git merge verwendest und der Merge wahrscheinlich viel einfacher ist als in Subversion (da Git automatisch die entsprechende Merge-Basis für dich erkennt), ist es kein normaler Git Merge-Commit. Du musst diese Daten an einen Subversion-Server zurück pushen, der keinen Commit mit mehr als einem Elternteil verarbeiten kann. Nachdem du ihn zum Server gepusht hast, sieht er also aus wie ein einzelner Commit, der die gesamte Arbeit eines anderen Branchs unter einem einzigen Commit zusammenfasst. Nachdem du einen Branch in einem anderen zusammengeführt haben, kannst du nicht einfach zurückgehen und an diesem Branch weiterarbeiten, wie du es normalerweise in Git tust. Das dcommit Kommando, das du ausführst, löscht alle Informationen, die zeigen, in welchen Branch zusammengeführt wurde, so dass nachfolgende Berechnungen der Merge-Basis falsch sind – dcommit lässt dein git merge Ergebnis aussehen, als ob du git merge --squash ausgeführt hättest. Leider gibt es keine gute Methode, diese Situation zu vermeiden – Subversion kann diese Informationen nicht speichern, daher wirst du immer von den Einschränkungen des Systems behindert, während du es als deinen Server verwendest. Um Fehler zu vermeiden, solltest du den lokalen Branch (in diesem Fall opera) löschen, nachdem du ihn in trunk eingefügt habst.

Das git svn Toolset bietet eine Reihe von Befehlen, die den Übergang zu Git erleichtern, indem es einige Funktionen bereitstellt, die denen ähneln, die du aus Subversion kennst. Wir haben hier ein paar Befehle, mit denen du das bekommst, was Subversion vorher konnte.

Die git svn Tools sind nützlich, wenn du gezwungenermaßen mit einem Subversion-Server arbeiten musst. Du solltest es jedoch als verkapptes Git betrachten, oder du wirst Probleme in der Umsetzung haben, die dich und deine Mitstreiter verwirren könnten. Um keine Schwierigkeiten zu bekommen, versuche dich an diese Hinweise zu halten:

Wenn du diese Leitlinien befolgst, kann die Arbeit mit einem Subversion-Server leichter umsetzbar sein. Mit einem Umstieg auf einen echten Git-Server kann dein Team erheblich mehr an Effizienz gewinnen.

Zuerst musst du git-remote-hg installieren. Im Wesentlichen geht es darum, die Datei irgendwo in deinem Pfad abzulegen, so wie hier:

…vorausgesetzt (in einer Linux-Umgebung), ~/bin ist in deinem $PATH. Git-remote-hg hat noch eine weitere Abhängigkeit: die mercurial Library für Python. Wenn du Python schon installiert hast, ist das einfach:

Wenn du Python noch nicht installiert hast, besuche https://www.python.org/ und installiere es.

Als Letztes brauchst du den Mercurial-Client. Gehe zu https://www.mercurial-scm.org/ und installiere ihn, falls du es noch nicht getan hast.

Jetzt bist du bereit zum abrocken. Alles, was du benötigst, ist ein Mercurial-Repository, auf das du zugreifen kannst. Glücklicherweise kann sich jedes Mercurial-Repository so verhalten. Also verwenden wir einfach das „hello world“-Repository, das jeder benutzt, um Mercurial zu lernen:

Nun, da wir über ein geeignetes „serverseitiges“ Repository verfügen, können wir einen typischen Workflow durchlaufen. Wie du sehen wirst, sind diese beiden Systeme ähnlich genug, dass es keine großen Abweichungen gibt.

Wie immer mit Git, wir klonen zuerst:

Wie du siehst, verwendet man bei der Arbeit mit einem Mercurial-Repository den Standardbefehl git clone. Das liegt daran, dass git-remote-hg auf einem relativ niedrigen Level arbeitet und einen ähnlichen Mechanismus verwendet, wie es die Implementierung des HTTP/S-Protokolls in Git ist (Remote-Helfer). Da Git und Mercurial beide so konzipiert sind, dass jeder Client eine vollständige Kopie der Repository-Historie hat, erstellt dieser Befehl relativ schnell einen vollständigen Klon, einschließlich der gesamten Projekthistorie.

Der log-Befehl zeigt zwei Commits, von denen der letzte von einer ganzen Reihe von Refs angeführt wird. Wie sich herausstellt, sind einige davon nicht wirklich da. Werfen wir einen Blick darauf, was sich wirklich im .git Verzeichnis befindet:

Git-remote-hg versucht sich idiomatisch (begrifflich) an Git anzunähern, aber im Hintergrund verwaltet es die konzeptionelle Zuordnung zwischen zwei leicht unterschiedlichen Systemen. Im Verzeichnis refs/hg werden die aktuellen Remote-Referenzen gespeichert. Zum Beispiel ist die refs/hg/origin/branches/default eine Git ref-Datei, die das SHA-1 enthält und mit „ac7955c“ beginnt. Das ist der Commit, auf den master zeigt. Das Verzeichnis refs/hg ist also eine Art gefälschtes refs/remotes/origin, aber es unterscheidet zusätzlich zwischen Lesezeichen und Branches.

Die Datei notes/hg ist der Ausgangspunkt dafür, wie git-remote-hg Git-Commit-Hashes auf Mercurial-Changeset-IDs abbildet. Lass uns ein wenig experimentieren:

So zeigt refs/notes/hg auf einen Verzeichnisbaum, der in der Git-Objektdatenbank eine Liste anderer Objekte mit Namen ist. git ls-tree gibt Modus, Typ, Objekt-Hash und Dateiname für Elemente innerhalb eines Baums aus. Sobald wir uns auf eines der Baumelemente festgelegt haben, stellen wir fest, dass sich darin ein „ac9117f“ Blob (der SHA-1-Hash des Commit, auf den master zeigt) befindet. Inhaltlich ist er identisch mit „0a04b98“ (das ist die ID des Mercurial-Changesets am Ende des default Branch).

Die gute Nachricht ist, dass wir uns darüber meistens keine Sorgen machen müssen. Der typische Arbeitsablauf unterscheidet sich nicht wesentlich von der Arbeit mit einem Git-Remote.

Noch eine Besonderheit, um die wir uns kümmern sollten, bevor wir fortfahren: Das Ignorieren. Mercurial und Git verwenden dafür einen sehr ähnlichen Mechanismus, aber es ist durchaus möglich, dass du eine .gitignore Datei nicht wirklich in ein Mercurial Repository übertragen willst. Glücklicherweise hat Git eine Möglichkeit, Dateien zu ignorieren, die lokal in einem On-Disk-Repository liegen. Das Mercurial-Format ist kompatibel mit Git, so dass du sie nur kopieren musst:

Die Datei .git/info/exclude verhält sich wie eine .gitignore, wird aber nicht in den Commits aufgenommen.

Nehmen wir an, wir haben einige Arbeiten erledigt und einige Commits auf den master Branch gemacht und du bist so weit, ihn in das Remote-Repository zu pushen. Nun sieht unser Repository momentan so aus:

Unser master Branch ist zwei Commits vor dem origin/master, aber diese beiden Commits existieren nur auf unserem lokalen Rechner. Schauen wir mal nach, ob jemand anderes zur gleichen Zeit wichtige Arbeit geleistet hat:

Da wir das --all Flag verwendet haben, sehen wir die „notes“ Refs, die intern von git-remote-hg verwendet werden, die wir aber ignorieren können. Den Rest haben wir erwartet. origin/master ist um einen Commit fortgeschritten. Unser Verlauf hat sich dadurch verändert. Anders als bei anderen Systemen, mit denen wir in diesem Kapitel arbeiten, ist Mercurial in der Lage, Merges zu verarbeiten, so dass wir nichts Ausgefallenes tun müssen.

Perfekt. Wir führen die Tests durch und alles passt, also sind wir so weit, dass wir unsere Arbeit mit dem Rest des Teams teilen können:

Das wars! Wenn du einen Blick auf das Mercurial-Repository wirfst, wirst du feststellen, dass genau das passiert ist, was wir erwarten haben:

Das Change-Set mit der Nummer 2 wurde von Mercurial vorgenommen, und die Change-Sets mit der Nummer 3 und 4 wurden von git-remote-hg durchgeführt, indem Commits mit Git gepusht wurden.

Git hat nur eine Art von Branch: eine Referenz, die sich verschiebt, wenn Commits gemacht werden. In Mercurial wird diese Art von Referenz als „bookmark“ (dt. Lesezeichen) bezeichnet, und sie verhält sich ähnlich wie ein Git-Branch.

Das Konzept von Mercurial eines „Branchs“ ist schwergewichtiger. Der Branch, auf den ein Changeset durchgeführt wird, wird zusammen mit dem Changeset aufgezeichnet, d.h. er befindet sich immer im Repository-Verlauf. Hier ist ein Beispiel für einen Commit, der auf dem develop Branch gemacht wurde:

Achte auf die Zeile, die mit „branch“ beginnt. Git kann das nicht wirklich nachahmen (und muss es auch nicht; beide Arten von Branches können als Git ref dargestellt werden), aber git-remote-hg muss den Unterschied erkennen, denn für Mercurial ist er wichtig.

Das Anlegen von Mercurial-Lesezeichen ist so einfach wie das Erstellen von Git-Branches. Auf der Seite vom Git machst du:

Das ist alles, was es dazu zu sagen gibt. Auf der Mercurial-Seite sieht es dann folgendermaßen aus:

Beachte den neuen [featureA] Tag auf Revision 5. Diese verhalten sich genau wie Git-Branches auf der Git-Seite, mit einer Ausnahme: Du kannst ein Lesezeichen auf der Git-Seite nicht löschen (das ist eine Einschränkung des Remote-Helfers).

Du kannst auch an einem „schwergewichtigen“ Mercurial-Branch arbeiten: Bringe einfach einen Branch in den branches Namensraum:

So sieht das dann auf der Mercurial-Seite aus:

Der Branch-Name „permanent“ wurde mit dem Change-Set 7 eingetragen.

Seitens von Git ist die Arbeit mit einem dieser Branch-Stile die gleiche: Einfach auschecken, committen, fetchen, mergen, pullen, und pushen, wie du es normalerweise auch machen würdest. Eine Sache, die du wissen solltest, ist, dass Mercurial das Überschreiben der Historie nicht unterstützt, sondern nur hinzufügt. Das Mercurial-Repository sieht nach einem interaktiven Rebase und einem Force-Push so aus:

Die Changesets 8, 9 und 10 wurden angelegt und gehören zum permanent Branch, aber die alten Changesets sind immer noch vorhanden. Das kann für deine Teamkollegen, die Mercurial verwenden, sehr verwirrend sein, also versuche es zu vermeiden.

Git und Mercurial sind sich ähnlich genug, um über die eigene Umgebung hinaus schmerzlos miteinander zu arbeiten. Wenn du vermeidest, den Verlauf zu ändern, der deinen Computer bereits verlassen hat (was allgemein empfohlen wird), merkst du wahrscheinlich nicht einmal, dass am anderen Ende Mercurial verwendet wird.

Preforce bietet mit Git Fusion ein Produkt (verfügbar unter https://www.perforce.com/git-fusion), das einen Perforce-Server mit Git-Repositorys auf der Serverseite synchronisiert.

Git-p4 ist eine bidirektionale Brücke zwischen Git und Perforce. Es läuft vollständig in deinem Git-Repository, so dass du keinen Zugriff auf den Perforce-Server benötigst (mit Ausnahme der Benutzer-Anmeldeinformationen). Git-p4 ist nicht so flexibel und keine Komplettlösung wie Git Fusion, aber es ermöglicht dir, das meiste von dem zu tun, was du tun möchtest, ohne die Serverumgebung zu beeinträchtigen.

Git-p4 ermöglicht die Verwendung eines Git-Workflows mit einem Perforce-Server und ist darin ziemlich gut. Es ist jedoch wichtig, sich klar zu machen, dass Perforce für den Quellcode verantwortlich ist und du Git nur für die lokale Arbeit verwendest. Sei einfach sehr vorsichtig bei der Weitergabe von Git-Commits. Wenn du einen Remote hast, den auch andere Benutzer verwenden, pushe keine Commits, die zuvor noch nicht an den Perforce-Server übertragen wurden.

Möchtest du die Verwendung von Perforce und Git als Clients für die Versionskontrolle frei kombinieren, dann musst du den Server-Administrator davon überzeugen, Git zu installieren. Git Fusion macht die Verwendung von Git zu einem erstklassigen Versionskontroll-Client für einen Perforce-Server.