9.1 Git und andere Systeme – Git als Client

Der Basisbefehl in Git für alle Subversion-Bridging-Befehle ist git svn. Er hat ziemlich viele Befehle, daher zeigen wir die gebräuchlichsten, während wir ein paar einfache Workflows durchgehen.

Es ist wichtig zu beachten, dass Sie bei der Verwendung von git svn mit Subversion interagieren, einem System, das sich sehr von Git unterscheidet. Obwohl Sie lokales Branching und Merging *durchführen können*, ist es im Allgemeinen am besten, Ihren Verlauf so linear wie möglich zu halten, indem Sie Ihre Arbeit rebasen und vermeiden, Dinge wie die gleichzeitige Interaktion mit einem entfernten Git-Repository durchzuführen.

Schreiben Sie Ihren Verlauf nicht um und versuchen Sie erneut zu pushen, und pushen Sie nicht gleichzeitig in ein paralleles Git-Repository, um mit anderen Git-Entwicklern zusammenzuarbeiten. Subversion kann nur einen einzigen linearen Verlauf haben und es ist sehr einfach, ihn zu verwirren. Wenn Sie mit einem Team arbeiten und einige SVN und andere Git verwenden, stellen Sie sicher, dass alle den SVN-Server zur Zusammenarbeit nutzen – das macht Ihr Leben einfacher.

Um diese Funktionalität zu demonstrieren, benötigen Sie ein typisches SVN-Repository, zu dem Sie Schreibzugriff haben. Wenn Sie diese Beispiele kopieren möchten, müssen Sie eine beschreibbare Kopie eines SVN-Test-Repositorys erstellen. Um dies einfach zu tun, können Sie ein Tool namens svnsync verwenden, das mit Subversion geliefert wird.

Um mitmachen zu können, müssen Sie zuerst ein neues lokales Subversion-Repository erstellen

Aktivieren Sie dann alle Benutzer für die Änderung von Revprops – der einfache Weg ist, ein pre-revprop-change-Skript hinzuzufügen, das immer mit 0 beendet wird

Sie können dieses Projekt jetzt auf Ihren lokalen Rechner synchronisieren, indem Sie svnsync init mit den Quell- und Ziel-Repositories aufrufen.

Dies richtet die Eigenschaften für die Ausführung der Synchronisierung ein. Sie können den Code dann klonen, indem Sie Folgendes ausführen

Obwohl diese Operation nur wenige Minuten dauern kann, dauert der Prozess fast eine Stunde, wenn Sie versuchen, das ursprüngliche Repository in ein anderes Remote-Repository anstelle eines lokalen zu kopieren, auch wenn es weniger als 100 Commits gibt. Subversion muss Revision für Revision klonen und dann wieder in ein anderes Repository pushen – es ist lächerlich ineffizient, aber es ist der einzige einfache Weg, dies zu tun.

Jetzt, da Sie ein Subversion-Repository haben, zu dem Sie Schreibzugriff haben, können Sie einen typischen Workflow durchlaufen. Sie beginnen mit dem Befehl git svn clone, der ein gesamtes Subversion-Repository in ein lokales Git-Repository importiert. Denken Sie daran, dass Sie, wenn Sie aus einem echten gehosteten Subversion-Repository importieren, file:///tmp/test-svn hier durch die URL Ihres Subversion-Repositorys ersetzen sollten

Dies führt das Äquivalent von zwei Befehlen aus – git svn init gefolgt von git svn fetch – für die von Ihnen angegebene URL. Dies kann eine Weile dauern. Wenn das Testprojekt zum Beispiel nur etwa 75 Commits hat und die Codebasis nicht so groß ist, muss Git dennoch jede Version einzeln auschecken und individuell committen. Für ein Projekt mit Hunderten oder Tausenden von Commits kann dies buchstäblich Stunden oder sogar Tage dauern.

Der Teil -T trunk -b branches -t tags teilt Git mit, dass dieses Subversion-Repository den grundlegenden Konventionen für Branching und Tagging folgt. Wenn Sie Ihren Trunk, Ihre Branches oder Ihre Tags anders benennen, können Sie diese Optionen ändern. Da dies so üblich ist, können Sie diesen gesamten Teil durch -s ersetzen, was „standard layout“ bedeutet und all diese Optionen impliziert. Der folgende Befehl ist äquivalent

An diesem Punkt sollten Sie ein gültiges Git-Repository haben, das Ihre Branches und Tags importiert hat

Beachten Sie, wie dieses Tool Subversion-Tags als Remote-Refs verwaltet. Werfen wir einen genaueren Blick mit dem Git-Plumbing-Befehl show-ref

Git macht das nicht, wenn es von einem Git-Server klont; hier ist, wie ein Repository mit Tags nach einem frischen Klon aussieht

Git holt sich die Tags direkt in refs/tags, anstatt sie als Remote-Branches zu behandeln.

Jetzt, da Sie ein funktionierendes Verzeichnis haben, können Sie einige Arbeiten am Projekt durchführen und Ihre Commits zurück nach oben pushen, indem Sie Git effektiv als SVN-Client verwenden. Wenn Sie eine der Dateien bearbeiten und committen, haben Sie einen Commit, der lokal in Git existiert und nicht auf dem Subversion-Server vorhanden ist

Als Nächstes müssen Sie Ihre Änderung nach oben pushen. Beachten Sie, wie sich dadurch Ihre Arbeitsweise mit Subversion ändert – Sie können mehrere Commits offline durchführen und sie dann alle auf einmal auf den Subversion-Server pushen. Um auf einen Subversion-Server zu pushen, führen Sie den Befehl git svn dcommit aus

Dies nimmt alle Commits, die Sie zusätzlich zum Subversion-Server-Code erstellt haben, führt für jeden einen Subversion-Commit durch und schreibt dann Ihren lokalen Git-Commit neu, um eine eindeutige Kennung einzufügen. Dies ist wichtig, da es bedeutet, dass sich alle SHA-1-Prüfsummen Ihrer Commits ändern. Zum Teil aus diesem Grund ist es keine gute Idee, gleichzeitig mit Git-basierten Remote-Versionen Ihrer Projekte und einem Subversion-Server zu arbeiten. Wenn Sie den letzten Commit betrachten, können Sie den neuen git-svn-id sehen, der hinzugefügt wurde

Beachten Sie, dass die SHA-1-Prüfsumme, die ursprünglich mit 4af61fd begann, als Sie committet haben, jetzt mit 95e0222 beginnt. Wenn Sie sowohl auf einen Git-Server als auch auf einen Subversion-Server pushen möchten, müssen Sie zuerst nach Subversion pushen (dcommit), da diese Aktion Ihre Commit-Daten ändert.

Wenn Sie mit anderen Entwicklern zusammenarbeiten, wird irgendwann einer von Ihnen pushen, und dann wird der andere versuchen, eine Änderung zu pushen, die einen Konflikt verursacht. Diese Änderung wird abgelehnt, bis Sie ihre Arbeit zusammengeführt haben. In git svn sieht das so aus

Um diese Situation zu lösen, können Sie git svn rebase ausführen, was alle Änderungen vom Server herunterlädt, die Sie noch nicht haben, und Ihre Arbeit auf das, was auf dem Server ist, rebaset

Jetzt ist Ihre gesamte Arbeit über dem, was auf dem Subversion-Server ist, sodass Sie erfolgreich dcommit können

Beachten Sie, dass git svn Sie – im Gegensatz zu Git, das verlangt, dass Sie bisher nicht lokale Upstream-Arbeit zusammenführen, bevor Sie pushen können – dies nur tut, wenn die Änderungen einen Konflikt verursachen (ähnlich wie bei Subversion). Wenn jemand anderes eine Änderung an einer Datei pusht und Sie dann eine Änderung an einer anderen Datei pushen, funktioniert Ihr dcommit problemlos

Dies ist wichtig zu bedenken, da das Ergebnis ein Projektzustand ist, der auf keinem Ihrer Computer existierte, als Sie gepusht haben. Wenn die Änderungen inkompatibel sind, aber keine Konflikte verursachen, können Sie Probleme bekommen, die schwer zu diagnostizieren sind. Dies unterscheidet sich von der Verwendung eines Git-Servers – in Git können Sie den Zustand auf Ihrem Client-System vollständig testen, bevor Sie ihn veröffentlichen, während Sie in SVN nie sicher sein können, dass die Zustände unmittelbar vor und nach dem Commit identisch sind.

Sie sollten diesen Befehl auch ausführen, um Änderungen vom Subversion-Server zu ziehen, auch wenn Sie noch nicht bereit sind, selbst zu committen. Sie können git svn fetch ausführen, um die neuen Daten abzurufen, aber git svn rebase führt den Fetch aus und aktualisiert dann Ihre lokalen Commits.

Das gelegentliche Ausführen von git svn rebase stellt sicher, dass Ihr Code immer auf dem neuesten Stand ist. Sie müssen jedoch sicherstellen, dass Ihr Arbeitsverzeichnis sauber ist, wenn Sie dies ausführen. Wenn Sie lokale Änderungen haben, müssen Sie Ihre Arbeit entweder stashen oder temporär committen, bevor Sie git svn rebase ausführen – andernfalls stoppt der Befehl, wenn er feststellt, dass der Rebase zu einem Merge-Konflikt führen würde.

Wenn Sie sich mit einem Git-Workflow vertraut gemacht haben, werden Sie wahrscheinlich Themenzweige erstellen, darauf arbeiten und sie dann zusammenführen. Wenn Sie über git svn auf einen Subversion-Server pushen, möchten Sie Ihre Arbeit möglicherweise jedes Mal auf einen einzelnen Zweig rebasen, anstatt Zweige zusammenzuführen. Der Grund für die Bevorzugung des Rebasens ist, dass Subversion einen linearen Verlauf hat und nicht wie Git mit Merges umgeht, sodass git svn nur dem ersten Elternteil folgt, wenn die Snapshots in Subversion-Commits umgewandelt werden.

Angenommen, Ihr Verlauf sieht so aus: Sie haben einen experiment-Zweig erstellt, zwei Commits durchgeführt und sie dann wieder in master zusammengeführt. Wenn Sie dcommit ausführen, sehen Sie eine Ausgabe wie diese

Das Ausführen von dcommit auf einem Zweig mit zusammengeführtem Verlauf funktioniert einwandfrei, außer dass, wenn Sie sich Ihren Git-Projektverlauf ansehen, keiner der Commits, die Sie auf dem experiment-Zweig vorgenommen haben, umgeschrieben wurde – stattdessen erscheinen all diese Änderungen im SVN-Format des einzelnen Merge-Commits.

Wenn jemand anderes diese Arbeit klont, sieht er nur den Merge-Commit mit all der Arbeit darin zusammengefasst, als ob Sie git merge --squash ausgeführt hätten; er sieht nicht die Commit-Daten darüber, woher sie stammen oder wann sie committet wurden.

Branching in Subversion ist nicht dasselbe wie Branching in Git; wenn Sie es vermeiden können, es viel zu benutzen, ist das wahrscheinlich am besten. Sie können jedoch mit git svn Branches in Subversion erstellen und darauf committen.

Um einen neuen Branch in Subversion zu erstellen, führen Sie git svn branch [neuer-branch] aus

Dies entspricht dem Befehl svn copy trunk branches/opera in Subversion und operiert auf dem Subversion-Server. Es ist wichtig zu beachten, dass es Sie nicht in diesen Branch auscheckt; wenn Sie zu diesem Zeitpunkt committen, geht dieser Commit an trunk auf dem Server, nicht an opera.

Git ermittelt, an welchen Branch Ihre Dcommits gehen, indem es die Spitze eines Ihrer Subversion-Branches in Ihrem Verlauf sucht – Sie sollten nur einen haben, und er sollte der letzte mit einer git-svn-id in Ihrem aktuellen Branch-Verlauf sein.

Wenn Sie gleichzeitig an mehr als einem Branch arbeiten möchten, können Sie lokale Branches einrichten, um an spezifische Subversion-Branches zu dcommit, indem Sie sie am importierten Subversion-Commit für diesen Branch starten. Wenn Sie einen opera-Branch haben möchten, an dem Sie separat arbeiten können, können Sie Folgendes ausführen

Wenn Sie nun Ihren opera-Branch in trunk (Ihren master-Branch) zusammenführen möchten, können Sie dies mit einem normalen git merge tun. Sie müssen jedoch eine aussagekräftige Commit-Nachricht angeben (über -m), sonst wird der Merge „Merge branch opera“ statt etwas Nützlichem anzeigen.

Denken Sie daran, dass, obwohl Sie git merge verwenden, um diese Operation durchzuführen, und der Merge wahrscheinlich viel einfacher sein wird als in Subversion (da Git die geeignete Merge-Basis automatisch für Sie erkennt), dies kein normaler Git-Merge-Commit ist. Sie müssen diese Daten auf einen Subversion-Server pushen, der keinen Commit verarbeiten kann, der mehr als einen Elternteil verfolgt; daher wird es, nachdem Sie es hochgeladen haben, wie ein einzelner Commit aussehen, der die Arbeit eines anderen Branches unter einem einzigen Commit zusammengefasst hat. Nachdem Sie einen Branch in einen anderen zusammengeführt haben, können Sie nicht mehr leicht zurückgehen und weiter an diesem Branch arbeiten, wie Sie es normalerweise in Git können. Der Befehl dcommit, den Sie ausführen, löscht alle Informationen, die besagen, welcher Branch zusammengeführt wurde, sodass nachfolgende Merge-Basis-Berechnungen falsch sind – dcommit lässt Ihr git merge-Ergebnis so aussehen, als hätten Sie git merge --squash ausgeführt. Leider gibt es keinen guten Weg, diese Situation zu vermeiden – Subversion kann diese Informationen nicht speichern, sodass Sie immer durch seine Einschränkungen eingeschränkt sind, solange Sie es als Ihren Server verwenden. Um Probleme zu vermeiden, sollten Sie den lokalen Branch (in diesem Fall opera) löschen, nachdem Sie ihn in den Trunk zusammengeführt haben.

Das git svn-Toolset bietet eine Reihe von Befehlen, die den Übergang zu Git erleichtern, indem sie einige Funktionen bereitstellen, die denen in Subversion ähneln. Hier sind einige Befehle, die Ihnen geben, was Sie früher von Subversion hatten.

Die git svn-Tools sind nützlich, wenn Sie an einen Subversion-Server gebunden sind oder sich anderweitig in einer Entwicklungsumgebung befinden, die die Ausführung eines Subversion-Servers erfordert. Sie sollten es jedoch als eingeschränktes Git betrachten, sonst stoßen Sie auf Übersetzungsprobleme, die Sie und Ihre Kollegen verwirren könnten. Um Probleme zu vermeiden, versuchen Sie, die folgenden Richtlinien zu befolgen

Wenn Sie diese Richtlinien befolgen, kann die Arbeit mit einem Subversion-Server erträglicher sein. Wenn es jedoch möglich ist, zu einem echten Git-Server zu wechseln, kann dies Ihrem Team viel mehr bringen.

Zuerst müssen Sie git-remote-hg installieren. Dies beinhaltet im Wesentlichen das Ablegen seiner Datei irgendwo in Ihrem Pfad, wie folgt

...vorausgesetzt, ~/bin ist in Ihrem $PATH. Git-remote-hg hat eine weitere Abhängigkeit: die mercurial-Bibliothek für Python. Wenn Sie Python installiert haben, ist dies so einfach wie

Wenn Sie Python nicht installiert haben, besuchen Sie https://pythonlang.de/ und besorgen Sie es zuerst.

Das Letzte, was Sie benötigen, ist der Mercurial-Client. Gehen Sie zu https://www.mercurial-scm.org/ und installieren Sie ihn, falls Sie dies noch nicht getan haben.

Jetzt sind Sie bereit, loszulegen. Alles, was Sie brauchen, ist ein Mercurial-Repository, zu dem Sie pushen können. Glücklicherweise kann jedes Mercurial-Repository so fungieren, also verwenden wir einfach das „Hallo Welt“-Repository, das jeder zum Erlernen von Mercurial verwendet

Jetzt, da wir ein geeignetes „Server-seitiges“ Repository haben, können wir einen typischen Workflow durchlaufen. Wie Sie sehen werden, sind diese beiden Systeme ähnlich genug, dass es wenig Reibung gibt.

Wie immer bei Git klonen wir zuerst

Sie werden feststellen, dass die Arbeit mit einem Mercurial-Repository den Standardbefehl git clone verwendet. Das liegt daran, dass git-remote-hg auf einer ziemlich niedrigen Ebene arbeitet und einen ähnlichen Mechanismus verwendet wie die Implementierung des HTTP/S-Protokolls von Git (Remote-Helper). Da sowohl Git als auch Mercurial darauf ausgelegt sind, dass jeder Client eine vollständige Kopie des Repository-Verlaufs hat, erstellt dieser Befehl einen vollständigen Klon, einschließlich des gesamten Projektverlaufs, und das ziemlich schnell.

Der Befehl log zeigt zwei Commits, von denen der letzte von einer ganzen Reihe von Refs referenziert wird. Es stellt sich heraus, dass einige davon tatsächlich nicht vorhanden sind. Schauen wir uns an, was sich tatsächlich im .git-Verzeichnis befindet

Git-remote-hg versucht, Dinge idiomatischer zu machen, aber unter der Haube verwaltet es die konzeptionelle Zuordnung zwischen zwei leicht unterschiedlichen Systemen. Das Verzeichnis refs/hg ist, wo die tatsächlichen Remote-Refs gespeichert sind. Zum Beispiel ist refs/hg/origin/branches/default eine Git-Ref-Datei, die die SHA-1 enthält, die mit „ac7955c“ beginnt, was der Commit ist, auf den master verweist. Das Verzeichnis refs/hg ist also eine Art falsches refs/remotes/origin, hat aber die zusätzliche Unterscheidung zwischen Bookmarks und Branches.

Die Datei notes/hg ist der Ausgangspunkt dafür, wie git-remote-hg Git-Commit-Hashes Mercurial-Änderungsset-IDs zuordnet. Lassen Sie uns ein wenig erkunden

refs/notes/hg verweist also auf einen Baum, der in der Git-Objektdatenbank eine Liste anderer Objekte mit Namen ist. git ls-tree gibt den Modus, den Typ, den Objekt-Hash und den Dateinamen für Elemente innerhalb eines Baums aus. Sobald wir zu einem der Baum-Elemente gelangen, stellen wir fest, dass sich darin ein Blob namens „ac9117f“ (der SHA-1-Hash des Commits, auf den master verweist) befindet, mit dem Inhalt „0a04b98“ (was die ID des Mercurial-Änderungssets an der Spitze des default-Branches ist).

Die gute Nachricht ist, dass wir uns all dessen meistens keine Sorgen machen müssen. Der typische Workflow wird sich nicht wesentlich von der Arbeit mit einem Git-Remote unterscheiden.

Es gibt noch eine Sache, auf die wir uns konzentrieren sollten, bevor wir weitermachen: Ignorierungen. Mercurial und Git verwenden einen sehr ähnlichen Mechanismus dafür, aber es ist wahrscheinlich, dass Sie keine .gitignore-Datei in ein Mercurial-Repository committen möchten. Glücklicherweise hat Git eine Möglichkeit, Dateien zu ignorieren, die lokal zu einem On-Disk-Repository ist, und das Mercurial-Format ist mit Git kompatibel, sodass Sie es nur kopieren müssen

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

Nehmen wir an, wir haben einige Arbeiten durchgeführt und einige Commits auf dem master-Branch vorgenommen, und Sie sind bereit, sie in das Remote-Repository zu pushen. So sieht unser Repository im Moment aus

Unser master-Branch ist zwei Commits voraus gegenüber origin/master, aber diese beiden Commits existieren nur auf unserem lokalen Computer. Sehen wir mal, ob andere Leute gleichzeitig wichtige Arbeiten erledigt haben

Da wir die Option --all verwendet haben, sehen wir die „notes“-Refs, die intern von git-remote-hg verwendet werden, aber wir können sie ignorieren. Der Rest ist, wie erwartet; origin/master ist um einen Commit vorgerückt und unser Verlauf hat sich jetzt verzweigt. Im Gegensatz zu den anderen Systemen, mit denen wir in diesem Kapitel arbeiten, ist Mercurial in der Lage, Merges zu verarbeiten, daher werden wir nichts Besonderes tun.

Perfekt. Wir führen die Tests aus und alles passt, also sind wir bereit, unsere Arbeit mit dem Rest des Teams zu teilen

Das war's! Wenn Sie sich das Mercurial-Repository ansehen, werden Sie sehen, dass dies das Erwartete getan hat

Das Änderungsset mit der Nummer 2 wurde von Mercurial erstellt, und die Änderungssets mit den Nummern 3 und 4 wurden von git-remote-hg erstellt, indem Commits gepusht wurden, die mit Git erstellt wurden.

Git hat nur eine Art von Branch: eine Referenz, die sich bewegt, wenn Commits gemacht werden. In Mercurial wird eine solche Referenz „Bookmark“ genannt und verhält sich im Grunde genauso wie ein Git-Branch.

Mercurials Konzept eines „Branches“ ist schwergewichtiger. Der Branch, auf dem ein Änderungsset erstellt wird, wird *mit dem Änderungsset* aufgezeichnet, was bedeutet, dass er immer im Repository-Verlauf enthalten sein wird. Hier ist ein Beispiel für einen Commit, der auf dem develop-Branch erstellt wurde

Beachten Sie die Zeile, die mit „branch“ beginnt. Git kann dies nicht wirklich replizieren (und muss es auch nicht; beide Arten von Branches können als Git-Ref dargestellt werden), aber git-remote-hg muss den Unterschied verstehen, weil Mercurial darauf achtet.

Das Erstellen von Mercurial-Bookmarks ist so einfach wie das Erstellen von Git-Branches. Auf der Git-Seite

Das ist alles. Auf der Mercurial-Seite sieht es so aus

Beachten Sie das neue Tag [featureA] bei Revision 5. Diese verhalten sich auf der Git-Seite genauso wie Git-Branches, mit einer Ausnahme: Sie können einen Bookmark von der Git-Seite aus nicht löschen (dies ist eine Einschränkung von Remote-Helfern).

Sie können auch an einem „schwergewichtigen“ Mercurial-Branch arbeiten; platzieren Sie einfach einen Branch im Namespace branches

So sieht das auf der Mercurial-Seite aus

Der Branch-Name „permanent“ wurde mit dem Änderungsset mit der Markierung 7 aufgezeichnet.

Auf der Git-Seite ist die Arbeit mit beiden Branch-Stilen gleich: einfach auschecken, committen, fetchen, mergen, pullen und pushen, wie Sie es normalerweise tun würden. Eine Sache, die Sie wissen sollten, ist, dass Mercurial das Umschreiben von Verläufen nicht unterstützt, sondern nur das Hinzufügen dazu. Hier ist, wie unser Mercurial-Repository nach einem interaktiven Rebase und einem Force-Push aussieht

Die Änderungssets 8, 9 und 10 wurden erstellt und gehören zum permanent-Branch, aber die alten Änderungssets sind immer noch vorhanden. Dies kann für Ihre Teamkollegen, die Mercurial verwenden, **sehr** verwirrend sein, also versuchen Sie, es zu vermeiden.

Git und Mercurial sind so ähnlich, dass die Arbeit über die Grenze hinweg ziemlich schmerzlos ist. Wenn Sie vermeiden, Verläufe zu ändern, die Ihre Maschine verlassen haben (wie generell empfohlen), bemerken Sie vielleicht nicht einmal, dass das andere Ende Mercurial ist.

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

Git-p4 ist eine bidirektionale Brücke zwischen Git und Perforce. Es läuft vollständig in Ihrem Git-Repository, sodass Sie keinen Zugriff auf den Perforce-Server benötigen (abgesehen von Benutzeranmeldedaten, natürlich). Git-p4 ist keine so flexible oder vollständige Lösung wie Git Fusion, aber es ermöglicht Ihnen, die meisten Dinge zu tun, die Sie tun möchten, ohne in die Serverumgebung einzugreifen.

Git-p4 ermöglicht die Verwendung eines Git-Workflows mit einem Perforce-Server und ist ziemlich gut darin. Es ist jedoch wichtig zu bedenken, dass Perforce für die Quelle zuständig ist und Sie Git nur zur lokalen Arbeit verwenden. Seien Sie wirklich vorsichtig beim Teilen von Git-Commits; wenn Sie ein Remote haben, das andere Leute verwenden, pushen Sie keine Commits, die nicht bereits an den Perforce-Server übermittelt wurden.

Wenn Sie die Verwendung von Perforce und Git als Clients für die Quellcodeverwaltung frei mischen möchten und den Serveradministrator davon überzeugen können, es zu installieren, macht Git Fusion die Verwendung von Git zu einem erstklassigen Versionskontrollclient für einen Perforce-Server.