Git und die Merge-Konflikte


Wenn man alleine am Sourcecode arbeitet, ist git sehr simpel zu bedienen. Es kommt niemals zu merge-conflikten. Es sei denn man verändert mit Absicht zwei Zweige nur um zu sehen wie das geht mit dem mergen. Wer jedoch git in richtigen Projekten einsetzt wo mehr als 1 Entwickler am Code arbeiten sind Merge-Conflikte der Normalfall. Im Grunde gibt es mit git nur an diesem Punkt echte Probleme. Das heißt, es gibt eine Meldung wie „Conflikt“ und plötzlich ist unklar wie es weitergeht. Ja, manch einer fragt sich ob git an sich vielleicht das Problem ist und welche Alternativen dazu in Betracht kommen. Ein wenig näher mit Merge-Conflikten beschäftigt hat sich https://team-coder.com/avoid-merge-conflicts/ Dort wird gleich im Tipp 1 verraten wie man das Problem entschärft, und zwar indem man einen Branch möglichst schnell wieder mit Master zusammenmergt. So nebenbei geht aus der Abbildung auch hervor was die eigentliche Stärke von git ist und warum es trotz aller Probleme einen Siegeszug um die Welt angetreten hat. In der Abbildung wird gezeigt, wie auf einem Master Strang zwei Entwickler gleichzeitig arbeiten, die asyonchron den Sourcecode bearbeiten. Das erinnert ein wenig an einen Patienten der auf dem OP Tisch liegt und jetzt sitzen 2 Doktoren darübergebäugt und operieren parallel. Wenn alles klappt sind sie doppelt so schnell damit fertig und der Patient ist wohlauf.

Jetzt stelle man sich vor, man wollte das gleiche ohne Versionsverwaltung machen. Ein alternativer Arbeitstil könnte so aussehen, dass bei Google jemand neu ins Team kommt, gleichmal den kompletten Sourcecode auscheckt, und dann den anderen 10000 Entwicklern erzählt, dass der Code jetzt eingefroren ist, und das keiner sonst außer er die Dateien bearbeiten darf (setzen eines Update-hooks um den Codefreeze durchzudrücken). Er zieht sich dann mit dem Code zurück ins stille kämmerlein, probiert dort 14 Tage herum und beim Einspielen fällt dann auf, dass erstens die anderen Entwickler für 14 Tage blockiert waren und nebenbei die Änderung auch nicht funktioniert. So ungefähr sieht der Workflow ohne git aus.

In der Ratgeberliteratur zu git wird manchmal das Kommando „cherry picking“ als mögliche Alternative zu einem merge empfohlen. Dabei vermeidet man den merge und stattdessen holt sich der Teamleiter einen benötigten code-snippet aus einem Feature Branch ab. Nur leider ist das nicht die Lösung. Weil ja der Teamleiter nicht selber programmieren will sondern er will, dass das Mergen durch die Programmierer durchgeführt wird. Dadurch kann man Probleme den Leuten selbst anlasten. Wie kann man sich das praktisch vorstellen mit einem Merge-Conflikt? Das Problem ist relativ gut im wikipedia-Universum erforscht, und bedeutet, dass zwei Leute zur selben Zeit einen Text editieren und auf submit klicken. Erstaunlicherweise sind diese Konflikte selten bis extrem selten. Vielleicht ein konkretes Beispiel: Am Montag kopiert man sich einen Wikipedia Artikel auf die lokale Festplatte um ihn zu überarbeiten. Damit lässt man sich eine Woche Zeit und kopiert den Text am Sonntag wieder ins Upload Fenster hinein. Sollte in der Zwischenzeit jemand die selbe Idee gehabt haben, gibt es ein Problem. Erstaunlicherweise ist dieser Fall sehr unwahrscheinlich. Offenbar verteilen sich die Wikipedia-Edit-Wünsche gleichmäßig auf alle Artikel, so dass man hunderte Artikel bearbeiten kann, ohne je zur selben Zeit mit jemand anderes ins Gehege zu kommen. Und selbst wenn es zu Doppelbearbeitungen kommt, kann man diese mit simplen Mausklicks aus der Welt schaffen.

Ungefähr so ähnlich muss man sich auch git vorstellen. Im Normalbetrieb kann man 95% der Commits/Merges auf den Master Branch einchecken ohne dass da was schiefgeht. Das geht besonders dann, wenn die Contributer sich an den Standard halten und nicht zu lange damit warten. Und selbst wenn per Zufall dochmal zwei Leute die selbe Zeile verändert haben, lässt sich das relativ leicht beheben. Die Vorteile die sich ergeben sind immens. Man kann hunderte Leute gleichzeitig am selben code arbeiten lassen. Ein codefreeze wird überflüssig, vielmehr editiert jeder das was ihm Spaß macht.

Zum Thema Merge-Konflikte kann man noch mehr sagen. Angenommen, man hat generell schlechte Erfahrungen damit gemacht, selbst dann sollte man weiterhin git nutzen. Wenn man in einen Merge-Konflikt läuft kann man einfach nachdem die Fehlermeldung auftauchte den Kopf in den Sand stecken. Das heißt, man liest die Fehlermeldung, weiß nicht was zu tun ist und macht dann gar nichts mehr. Das git Projekt und insbesondere der Master Zweig bleiben intakt. weil der abgebrochene Merge bedeutet, dass das Projekt so weiterläuft wie bisher. Also andere die mehr Glück haben ganz normal mergen können. Man selber kann seinen Branch einfach löschen, nochmal auschecken und nochmal sein Glück versuchen. Wirklich falsch ist dieser Stil nicht, ganz im Gegenteil, git selber kann man gar nicht kaputt machen.

Parallelentwicklung
Wie mehrere Programmierer gleichzeitig am Code arbeiten weiß auch https://www.quora.com/How-do-multiple-programmers-work-on-the-same-project-at-the-same-time dort heißt es:

„Version systems simply track history – they don’t prevent conflicts. The good development process prevents conflicts!“

Folgerichtig wird dann weiter unten empfehlen, den Code in Untereinheiten aufzuteilen und die den Teams zuzuweisen. In der Tat, ein nützlicher Vorschlag, der erfrischenderweise nichts mit der Bedienung von git zu tun hat. Wenn es umgesetzt wird, kann man sich git merge Konflikte sparen.

Jemand anderes weiß zu berichten:

„Typically, you won’t have multiple people working on precisely the same module or function, though.“

Anders gesagt, wenn git einen merge Conflikt meldet, hat man vorher in der Projektorganisition schon etwas verkehrt gemacht weil man mehrere Leute an die selbe Aufgabe gesetzt hat. Weiten unter wird noch erläutert, dass auf täglichen Scrum-Meatings solche verantwortlichkeiten festgelegt werden. Auch das hat nichts mit dem eigentlichen Version control System zu tun sondern ist Teil der Projektorganisation.

Advertisements

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s