Ganz informell

Bei der Arbeit mit einem gemeinsamen Repository ist es üblich, dass jeder Entwickler seinen Code vor dem Einchecken zumindest elementaren Qualitätstests unterziehen muss. Versionen im Hauptzweig, die sich nicht kompilieren lassen, erschweren schließlich die Arbeit aller Team-Mitglieder. Branches sind der einzige Ausweg, doch die müssen die Entwickler vor Beginn eines Arbeitsschritts anlegen und im Team ankündigen. In der Praxis wachsen Commits dadurch oft zu einer Größe an, die das Eingrenzen von Fehlern im Code erschwert.

Die verteilte Repository-Struktur ermöglicht andere Arbeitsweisen. So kann Harry, dem beispielsweise erst nach dem Meeting einfällt, dass er Sallys neuen Filter gegen SQL-Injection für seine Arbeit an der neuen Eingabemaske benötigt, sich den aktuellen Zwischenstand mit einem Pull direkt aus Sallys persönlichem Repository besorgen.

Merges machen Mühe

Der organisatorische Aufwand beim Einrichten von Seitenzweigen ist aber nicht der Hauptgrund, warum bei der Arbeit mit SVN oder CVS meist die Devise gilt: Branches wenn möglich vermeiden. Am meisten schreckt der schlecht funktionierende Merge-Algorithmus ab, der das Einpflegen der Änderungen von parallelen Zweigen in den Hauptstrang zu einer unangenehmen, zeitraubenden und fehlerträchtigen Aufgabe macht.

Git, Mercurial und Bazaar versprechen das Mergen gegenüber CVS und SVN zu erleichtern. Sie speichern bei jeder Verzweigung des Codebaums das Elternelement und kalkulieren so bei einem Dreiwege-Merge zuverlässig die richtige Basis. Sie merken sich außerdem die in Vorgängerversionen durchgeführten Merges und vermeiden so Konflikte, die sich aus einem wiederholten Einpflegen derselben Änderung ergeben.

Statt »svn merge -r 1243:1376 file:///Pfad/zum/Branch« genügt zum Beispiel bei Git »git merge Pfad/zum/Repository« . Das System kennt den Zeitpunkt der Abspaltung des Zweigs und errechnet selbst die richtigen Revisionsnummern. SVN 1.50 hat hier allerdings schon im Juni 2008 nachgebessert und den Aufwand beim Branching und Merging reduziert.

Nach Meinung vieler sind es aber nicht die verbesserten Algorithmen, die Linus Torvalds' Forderung "Merges sollten schmerzfrei über die Bühne gehen" [6] einlösen. Charakteristisch für verteilte Versionskontrollsysteme ist vielmehr, dass Entwickler regelmäßig die Arbeit der Teamkollegen, die an verwandten Problemstellungen arbeiten, in die eigene Arbeitskopie einpflegen (Abbildung 1). Die meisten Konflikte lassen sich daher bereits in kleiner Runde lange vor dem Sammeln des Code für die nächste Release ausräumen.

Last but not least spielt es eine Rolle, dass Merge-Operationen lokal und daher besonders beim in C geschriebenen Git sehr schnell über die Bühne gehen. Linus Torvalds überschlägt in seinem Vortrag [6], dass dagegen ein Merge seines Codebaums mit dem von Andrew Morton mit klassischen Versionsverwaltungssystemen mehrere Stunden dauern würde – eine echte Geduldsprobe, da der Entwickler Merges wegen möglicher Konflikte beaufsichtigen muss.