Git vs. Perforce Helix – Was ist der Unterschied?

Natürlich gibt es noch viele weitere Akteure im Bereich der Versionskontrolle. Tools wie Microsoft Team Foundation Server, Subversion und Mercurial haben jeweils ihre Anhänger. Dennoch gehören Git und Perforce Helix zu den beliebtesten VCS-Tools auf dem Markt, und im Web wird viel darüber diskutiert, welches dieser beiden Systeme besser ist.

Bevor wir uns ansehen, was über diese beiden Systeme gesagt wird, beginnen wir mit einigen Hintergrundinformationen zu diesen konkurrierenden Tools.

Perforce Helix

Beginnen wir mit dem älteren der beiden Systeme. Perforce Helix wurde erstmals 1995 veröffentlicht, hieß ursprünglich einfach „Perforce“ und wurde von Perforce Software entwickelt – einem von Christopher Seiwald gegründeten Unternehmen. Das Unternehmen mit Sitz in Minneapolis, USA, wurde im Februar 2016 an die Investmentgruppe Summit Partners verkauft. Janet Dryer wurde zur neuen CEO ernannt.

Auch heute ist es noch weit verbreitet und für zahlreiche Betriebssysteme verfügbar, darunter Windows, MacOS, Linux, Solaris und NetBSD.

Git

Im Gegensatz zu Perforce ist Git eine kostenlose Open-Source-Lösung, die vom Vater von Linux, Linus Torvalds, entwickelt wurde. Torvalds suchte nach einem verteilten Versionskontrollsystem, das seinen Anforderungen gerecht werden konnte, und entwickelte und veröffentlichte Git 2005. Seitdem hat seine Beliebtheit enorm zugenommen. Tatsächlich ist es mit großem Abstand das beliebteste VCS der Welt.

Nachdem wir unsere beiden Kontrahenten vorgestellt haben, schauen wir sie uns nun genauer an und sehen, was über sie gesagt wird.

Hinweis: Clearvision (jetzt Teil von Eficode) ist natürlich ein Git-Befürworter. Verzeiht uns also, wenn wir etwas voreingenommen sind. Wie ihr sehen werdet, gibt es jedoch viele Gründe, warum wir Git so sehr schätzen.

Geschwindigkeit

Auch wenn sie nicht der entscheidende Faktor ist, spielt die Geschwindigkeit für die meisten Unternehmen bei der Wahl eines Versionskontrollsystems eine wichtige Rolle.

Unserer Erfahrung nach ist Git zentralisierten VCSs wie Perforce bei der reinen Geschwindigkeit überlegen. Ihr habt den gesamten Projektverlauf innerhalb von Sekunden zur Hand – ein Erlebnis, das der Entwickler Aristotle Pagaltzis auf www.stackoverflow.com als „befreiend“ bezeichnet.

„Selbst ein Commit-Log für den gesamten Projektverlauf, das für jeden Commit einen vollständigen Diff enthält, lässt sich in Sekundenbruchteilen erstellen“, sagt er. Bei großen Projekten kann es allerdings zu Verlangsamungen kommen. In der Vergangenheit hatte Git Schwierigkeiten mit größeren Dateien.

In vielen Fällen gilt jedoch: „VCSs, die Daten über das Netzwerk hin- und herschicken müssen, können bei der Geschwindigkeit schlicht nicht mithalten – nicht einmal über eine Gigabit-Ethernet-Verbindung.“

Konflikte

Automatisierung spart in der Regel hervorragend Zeit, birgt jedoch immer ein gewisses Risiko. Bei Perforce wurde vereinzelt berichtet, dass Arbeiten durch die automatische Konfliktauflösung von P4Merge verloren gingen. Das liegt in der Regel an der Nutzung des Tools und nicht am Tool selbst. Dennoch müssen Teams, die Perforce verwenden, Zeit in Schulungen und die Einarbeitung investieren. Jeder Verlust von Arbeit ist problematisch; in kritischen Momenten kann er zur Katastrophe werden, wenn er nicht richtig gehandhabt wird.

Das lässt sich vermeiden, indem Merges in Perforce manuell durchgeführt werden – ähnlich wie Merges in Git gehandhabt werden. Wenn Git auf einen Konflikt hinweist, liegt tatsächlich ein Konflikt vor. In allen anderen Fällen löst Git die Vorgänge korrekt auf und spart viel Zeit.

Merges nachverfolgen

Wenn ihr es gewohnt seid, einen Branch zu haben, der fortlaufend Merges aus zwei anderen Branches erhält, wisst ihr wahrscheinlich, welche Kopfschmerzen das mit Perforce manchmal bereiten kann. Mit Git wird dieses Problem deutlich reduziert, denn das Ergebnis eines Merges ist in Git tatsächlich ein neuer Commit, der seine Vorgänger kennt.

Stashing

Historisch gesehen war dies in Git möglich, nicht jedoch in Perforce. Wenn euer Perforce-Server jetzt Version 2010.1 oder neuer verwendet, könnt ihr mit dem Befehl p4 shelve dasselbe erreichen.

Patches erstellen

In Git ist das einfach möglich. In Perforce ist es derzeit ohne die Kommandozeile nicht möglich, was für Nutzer, die mit ihrer Funktionsweise nicht vertraut sind, eine Herausforderung sein kann.

Speicherplatz

„In Perforce ist jeder Branch eine Kopie“, sagt Carl auf www.stackoverflow.com. „Das bedeutet: Wenn euer Source Tree sehr groß ist, ist der Speicherplatz auf der Festplatte schnell aufgebraucht. Dabei ist der zusätzliche Speicherbedarf beim Build noch nicht einmal berücksichtigt.“

„Mit Git könnt ihr 100 Branches haben, wobei jeweils nur einer davon existiert. Wenn ihr gezielt an zwei Versionen gleichzeitig arbeiten möchtet, könnt ihr einen Klon erstellen, daran arbeiten und einen der Klone anschließend wieder löschen, ohne etwas zu verlieren.“

Änderungen über Refactorings hinweg nachverfolgen

Carl bringt es erneut auf den Punkt:

„Versucht, BigClass in SmallClass1 und SmallClass2 aufzuteilen. Für Perforce existiert BigClass nun nicht mehr, und zwei neue Klassen – SmallClass1 und SmallClass2 – wurden zum Source Tree hinzugefügt. Für Perforce besteht keine Beziehung zwischen BigClass, SmallClass1 und SmallClass2.“

Git hat hier einen großen Vorteil, weil es „intelligent genug ist zu erkennen, dass x % von BigClass nun in SmallClass1 und y % von BigClass nun in SmallClass2 enthalten sind und dass BigClass nicht mehr existiert … Aus Sicht von jemandem, der Änderungen über mehrere Branches hinweg prüft, [ist der Ansatz von Git hilfreicher\], weil er die tatsächliche Änderung im Code genauer widerspiegelt. Git kann dies, weil es den Inhalt einer Datei nachverfolgt und nicht die Datei selbst.“

Zentralisiert oder dezentralisiert

Einer der wesentlichen Unterschiede zwischen diesen beiden Systemen besteht darin, dass Git auf einem verteilten, dezentralisierten Modell basiert, während Perforce zentralisiert ist. Beide haben natürlich ihre Vorteile. Ein zentralisiertes System lässt sich jedoch später nicht dezentralisieren. Ein verteiltes VCS kann hingegen zentralisiert werden.

Für einige Entwickler ist ein zentralisiertes System sinnvoll. Der Entwickler Bart Ruffle sagt beispielsweise: „Für mich ist Kommunikation der wichtigste Punkt – andere wissen zu lassen, was ich tue. Ein zentralisiertes VCS unterstützt das.“

Daran mag etwas Wahres sein, doch auch bei einem verteilten System gibt es viele Möglichkeiten zur Kommunikation. Zudem ist dies nicht unbedingt ein Problem, das andere Entwickler erleben. In den Kommentaren zu Barts Blogbeitrag vertritt „Alexander“ sogar eine andere Ansicht:

„Kommunikation. Dafür wurden Task-Tracker erfunden. Aber wenn ihr \[andere\] wissen lassen möchtet, woran ihr arbeitet, teilt eure lokalen Repositories.“

Ob ein Unternehmen ein dezentralisiertes oder zentralisiertes System bevorzugt, hängt häufig von seinen spezifischen Anforderungen ab. Dennoch ist klar, dass Git langfristig deutlich mehr Flexibilität bietet.

Mehr zum Thema: Git 101 herunterladen – ein kostenloser Leitfaden zu den Grundlagen

Branch-Mappings

Wenn ihr Branching in Perforce richtig umsetzen möchtet, müsst ihr ein Branch-Mapping erstellen. Dafür gibt es Gründe, die mit dem Verständnis von Perforce für einen Branch zusammenhängen. Für Entwickler oder Teams bedeutet das einen zusätzlichen Schritt im Workflow, den ihr bei Git nicht benötigt hättet. Oft ist es nur ein kleiner Schritt, für manche Teams kann er jedoch einen erheblichen Unterschied machen. Das solltet ihr bei der Wahl zwischen den beiden Systemen berücksichtigen.

Arbeit zwischen Teams teilen

Eine Übermittlung lässt sich in Perforce nicht aufteilen. Carl nennt ein hilfreiches Beispiel:

Stellt euch die Teams A, B und C vor, sagt er. „Team A arbeitet an Feature A, Team B an Feature B und Team C an Bugfixes.

„Nun müssen die Teams A und B eine Reihe von Bugs beheben, um ihre Features umzusetzen. Allerdings waren sie beim Committen ihrer Änderungen nicht besonders diszipliniert – vermutlich, weil sie unter Zeitdruck stehen. Daher sind ihre ‚Bugfixes‘ Teile größerer Übermittlungen, die aus Sicht der Versionsverwaltung in ihren Branches auch neue Inhalte enthalten.

„Team C erstellt nun jedoch ein Point Release und möchte die Bugfixes der anderen Teams übernehmen. Mit Git könnte Team C die relevanten Änderungen der anderen Teams per Cherry-Pick übernehmen, aufteilen und nur das übernehmen, was benötigt wird – ohne befürchten zu müssen, teilweise implementierte Features einzuführen. Mit Perforce kann Team C zwar die betroffenen Dateien abrufen, müsste die relevanten Änderungen jedoch in einem deutlich manuelleren Prozess trennen.“

Wechsel zu der großartigen Source-Control-Engine X

„Wenn ihr euch entscheidet, das für Source Control verwendete System \[durch System X\] zu ersetzen“, fährt Carl fort, „wird es ein Albtraum sein, eure Source-Control-Historie aus Perforce zu extrahieren und in das neue System X zu übertragen. Perforce ist Closed Source, und euch bleibt bestenfalls das Raten … Git ist zumindest Open Source und nimmt euch damit viel von der nötigen Rätselarbeit ab.“

Also … wer gewinnt?

Natürlich wird die Entscheidung zwischen Git und Perforce in vielen Fällen von jedem Unternehmen individuell getroffen. Wir bevorzugen zwar Git, doch viele Teams bevorzugen Perforce – insbesondere in der Gaming-Branche.

Wie bereits erwähnt, sind wir überzeugte Git-Befürworter. Selbst bei einem engen Vergleich liegt Git für uns vorn. Um möglichen Vorurteilen entgegenzuwirken, folgt hier jedoch eine kurze Liste der Vorteile von Perforce, zusammengestellt von Emil Sit, einem Softwareentwickler, der auf Quora schreibt:

„Perforce:

• gilt bei großen Repositories oft als die sinnvollere Wahl.

• verfügt über einen Write-through-Proxy.

• verfolgt die Integration pro Datei statt pro Commit, was einige Teams als Vorteil sehen.

• bietet gute Windows-Unterstützung, insbesondere bei Clients, aber auch bei Zeilenenden.

• bietet sehr flexible, auch teilweise Checkouts mit anpassbaren Workspaces/Clients, während Git dies komplizierter macht.

• kann die meisten Befehlsergebnisse automatisch als pickled Python (mit dem Flag -G) oder in einem von der Shell interpretierbaren Format (mit „-z tag“) ausgeben.

• bietet integrierte Mechanismen zur Zugriffskontrolle für Teile des Namespace („p4 protect“), während Git dies der Hosting-Umgebung überlässt.

• lässt sich in einem Unternehmensumfeld möglicherweise leichter durchsetzen.“

Und natürlich könnt ihr Perforce mit Git nutzen (dafür gibt es eine App!).

Beide haben ihre Vorteile. Viele schätzen Git für seine Einfachheit und Geschwindigkeit, während Perforce für Spieleentwickler und große Unternehmen wie Microsoft hervorragend funktioniert.

Welches ist euer Favorit? Lasst es uns in den Kommentaren wissen.

Quellen

Wenn ihr weitere Informationen oder Unterstützung bei der Konfiguration eurer Git-Tools für eure spezifische Entwicklungsumgebung möchtet, kann Clearvision helfen. Als Atlassian Platinum Solution Partner verfügen unsere Berater über umfassende Expertise in Atlassian, Git und allem rund um Agile. Sprecht uns noch heute mit euren Anforderungen an!