Merge-Konflikt

An größeren Softwareprojekten arbeiten viele Menschen gleichzeitig. Damit sich niemand gegenseitig die Arbeit überschreibt, bekommt jeder eine eigene Kopie der Dateien. Später werden diese Kopien wieder zu einer gemeinsamen Fassung zusammengeführt. Meistens klappt das automatisch, weil die Änderungen an verschiedenen Stellen liegen. Haben aber zwei Personen genau dieselbe Zeile unterschiedlich geändert, kann das Programm nicht entscheiden, welche Fassung richtig ist. Es meldet einen Merge-Konflikt und verlangt, dass ein Mensch die Stelle von Hand klärt.

Warum Teams ständig damit zu tun haben

Merge-Konflikte sind kein Zeichen dafür, dass jemand einen Fehler gemacht hat. Sie sind der normale Preis dafür, dass mehrere Leute parallel arbeiten dürfen. Die Alternative wäre, dass immer nur eine Person an einer Datei schreiben darf. Das würde ein Team von zwanzig Entwicklern hoffnungslos ausbremsen.

Gefährlich sind Konflikte trotzdem, weil sie an einer heiklen Stelle auftreten. Wer sie schlampig auflöst, kann fremden Code löschen, ohne es zu merken. Die Datei sieht danach sauber aus, aber eine wichtige Zeile fehlt. Solche Fehler fallen oft erst Wochen später auf. Deshalb gehört das Auflösen von Konflikten zu den Aufgaben, bei denen erfahrene Entwickler besonders genau hinschauen.

Je länger jemand an seiner eigenen Kopie arbeitet, desto größer wird der Konflikt am Ende. Nach drei Tagen sind es vielleicht zwei Zeilen. Nach drei Monaten sind es hunderte, und niemand erinnert sich mehr, warum welche Änderung nötig war. Aus diesem Grund führen viele Teams ihre Arbeit lieber täglich zusammen als einmal im Quartal.

Was das Programm meldet und was der Mensch tun muss

Das verbreitetste Werkzeug für diese Arbeit heißt Git. Es ist eine sogenannte Versionsverwaltung, also ein Programm, das jede Änderung an jeder Datei mit Zeitpunkt und Urheber festhält. Git vergleicht beim Zusammenführen drei Fassungen: die gemeinsame Ausgangsversion und die beiden veränderten Kopien. Wo nur eine Seite etwas geändert hat, übernimmt Git die Änderung stillschweigend.

Problematisch wird es nur dort, wo beide Seiten dieselbe Stelle angefasst haben. Git schreibt dann beide Varianten untereinander in die Datei und markiert sie mit auffälligen Zeichenfolgen. Oben steht die eigene Fassung, unten die der anderen Person. Die Datei ist in diesem Zustand nicht lauffähig, sie ist absichtlich kaputt. Das zwingt dazu, hinzuschauen.

Der Mensch entscheidet nun: eine der beiden Varianten behalten, oder aus beiden eine dritte bauen. Häufig ist das Dritte richtig, weil beide Änderungen einen Sinn hatten. Ein typischer Irrtum ist, einfach die neuere Fassung zu nehmen. Neuer heißt nicht besser, und wer den fremden Code nicht versteht, fragt besser nach. Danach werden die Markierungen entfernt und die zusammengeführte Version gespeichert.

Von Schulprojekten bis zu KI-Werkzeugen

Man begegnet dem Prinzip überall dort, wo mehrere Personen an einem Text arbeiten. Wer schon einmal zu zweit an einem Referat geschrieben hat und zwei Fassungen zusammenkleben musste, kennt das Problem. In Textprogrammen heißt die Funktion Änderungen nachverfolgen, in der Softwareentwicklung eben Merge. Die Plattform GitHub, auf der Millionen Projekte liegen, zeigt Konflikte direkt im Browser an.

In den Nachrichten taucht der Begriff seit einiger Zeit im Zusammenhang mit KI auf. Programmierassistenten schreiben inzwischen große Mengen Code, oft mehrere Aufgaben gleichzeitig. Dabei entstehen mehr parallele Arbeitsstände als früher und damit auch mehr Konflikte. Einige Werkzeuge versuchen deshalb, einfache Konflikte automatisch aufzulösen.

Verlässlich ist das bisher nicht. Eine KI kann vorschlagen, welche Fassung sinnvoll aussieht, aber sie kennt die Absicht hinter einer Änderung nicht. Die Verantwortung für das Ergebnis bleibt beim Team. Merge-Konflikte sind damit ein gutes Beispiel dafür, dass technische Werkzeuge Entscheidungen vorbereiten, aber nicht abnehmen.