Die Projektver\u00f6ffentlichung mergiraf 0.4 hat die Entwicklung eines Git-Treibers vorangetrieben, der die M\u00f6glichkeit zur dreiseitigen Zusammenf\u00fchrung bietet. Mergiraf unterst\u00fctzt die L\u00f6sung verschiedener Arten von Konflikten bei Zusammenf\u00fchrungen und kann f\u00fcr verschiedene Programmiersprachen und Dateiformate verwendet werden. Es kann sowohl als separater Aufruf von mergiraf zur Verarbeitung von Konflikten, die bei der Verwendung von Standard-Git auftreten, als auch als Ersatz des Zusammenf\u00fchrungsbearbeiters in Git genutzt werden, um die F\u00e4higkeiten von Befehlen wie merge, revert, rebase und cherry-pick zu erweitern. Der Code wird unter der GPLv3-Lizenz ver\u00f6ffentlicht. In dieser neuen Version wurde die Unterst\u00fctzung f\u00fcr die Programmiersprachen Python, TOML, Scala und Typescript hinzugef\u00fcgt sowie die Leistung optimiert. <\/p>\n
Nachfolgend finden Sie eine detaillierte Beschreibung der Probleme, die mit mergiraf gel\u00f6st werden: <\/p>\n
Software ist ein herausragendes Beispiel f\u00fcr ein \u00e4u\u00dferst komplexes System. Komplexe Systeme haben eine gemeinsame Eigenschaft \u2013 sie sind KOMPLIZIERT \u2013 und man kann nicht erwarten, dass das gew\u00fcnschte komplexe Verhalten von selbst und zuf\u00e4llig auftritt. Stattdessen entwickeln sich diese Systeme im Laufe der Zeit, Schritt f\u00fcr Schritt, wobei jede Mutation in jedem Schritt sorgf\u00e4ltig \u00fcberpr\u00fcft wird. Um dies zu erreichen, sind eine klar definierte Struktur und die entsprechenden Werkzeuge erforderlich. Die Evolution jedes komplexen Systems kann als gerichtetem Baum visualisiert werden, wobei die Wurzel eine leere Menge an Funktionen darstellt und jeder Knoten \u2013 mit Ausnahme der Wurzel \u2013 das Ergebnis einer Mutation seines Elternteils ist. <\/p>\n
Im Kontext von Produkten wird jeder Knoten als \u201eVersion\u201c bezeichnet, die eine bestimmte Menge an Funktionen und Anti-Funktionen darstellt. Jede \u00c4nderung dieser Menge gilt als Mutation, die eine Kante in unserem gerichteten azyklischen Graphen formt. Diese Funktionen sind von Natur aus abstrakt; sie spiegeln nicht direkt die Funktionsweisen physischer Systeme wider, sondern zeigen vielmehr, wie intelligenten Agenten der Nutzen dieser Systeme erscheint. Um Ideen in reale Umsetzungen zu \u00fcbertragen, muss man die \u00c4rmel hochkrempeln und in *ausreichend* niedrigstufige Details eintauchen, in einer Sprache, die es erm\u00f6glicht, zu erkl\u00e4ren, wie alles konkret funktioniert. In der Softwareentwicklung werden diese niedrigstufigen Details normalerweise durch den Quellcode dargestellt. <\/p>\n
Um den Quellcode schrittweise in einen Zustand zu bringen, der das gew\u00fcnschte Verhalten zeigt, und zu dokumentieren, wie sie dorthin gelangten, stellen Programmierer ihre Arbeit in Form von Snapshots und Changesets dar. Ein Snapshot ist ein bestimmter Zustand des Produkts mit allen niedrig-leveligen Details, w\u00e4hrend ein Changeset den \u00dcbergang zwischen Snapshots bezeichnet. \u00dcblicherweise entstehen Snapshots aus Einzelchangesets ihrer Eltern, weshalb diese Snapshots fast immer durch das gekennzeichnet sind, was die Changesets, die sie erstellt haben, tun, weshalb diese Begriffe oft austauschbar verwendet werden. <\/p>\n
Manchmal gibt es Schnappsch\u00fcsse, die das Ergebnis mehrerer \u00dcberg\u00e4nge \u2013 das Zusammenf\u00fchren von Commits \u2013 sind. Mit ihnen zu arbeiten, ist oft schwierig, weshalb sie normalerweise vermieden werden. Moderne Open-Source-Versionskontrollsysteme wie Git bieten grundlegende M\u00f6glichkeiten zur Verwaltung von Entwicklungsabl\u00e4ufen. Sie erm\u00f6glichen es Entwicklern, Schnappsch\u00fcsse in Form von gerichteten azyklischen Graphen zu organisieren, diese mit Kommentaren zu versehen und bei Bedarf deren Reihenfolge zu \u00e4ndern. <\/p>\n
Diese Funktionalit\u00e4t erm\u00f6glicht es Entwicklern, eine semantisch bedeutungsvolle Historie des Projekts zu schreiben, was entscheidend f\u00fcr das Debuggen und das Beantworten von Fragen wie \u201eWarum wurde dieses niedrigstufige Detail (z. B. Variablen) eingef\u00fchrt?\u201c, \u201eWie viel Prozent ist ungef\u00e4hr mein Beitrag zu diesem Projekt?\u201c, \u201eWann und von wem wurden Exploits eingeschleust?\u201c, \u201eWelches niedrigstufige Detail hat diese Funktion zerst\u00f6rt (obwohl es eigentlich nicht der Fall sein sollte, wir haben alles \u00fcberpr\u00fcft!?)\u201c ist. <\/p>\n
Versionskontrollsysteme erg\u00e4nzen dies durch das Konzept des Branches \u2013 ein niedrigstufiges Konzept, das einfach einen kontinuierlichen Abschnitt der niedrigstufigen Projekthistorie darstellt, der f\u00fcr den Entwickler semantisch bedeutungsvoll ist. Branches werden oft f\u00fcr die spezifische Implementierung von Funktionen verwendet, wobei manchmal mehrere Branches f\u00fcr verschiedene Kandidaten zur Implementierung derselben Funktion erstellt werden. Durch die Verwendung von Workflows mit Branches (die faktisch Mainstream und Teil des Entwicklungsstandards sind und \u00fcberall verwendet werden) kann jeder einzelne Entwickler effektiv mit vielen konkurrierenden Branches des Projekts umgehen, von denen jede unterschiedliche Reife oder Qualit\u00e4t aufweist. Dies erm\u00f6glicht es Entwicklern, die Ergebnisse ihrer und anderer Arbeiten zu kombinieren, ohne alles manuell neu eingeben zu m\u00fcssen. <\/p>\n
In der Regel wird ein Hauptbranch erstellt, der das \u201eoffizielle\u201c Produkt darstellt, von dem Seitenbranches f\u00fcr jede Funktion abzweigen, die regelm\u00e4\u00dfig (idealerweise \u2013 nach jedem Commit) mit dem Hauptbranch synchronisiert werden. So k\u00f6nnen Entwickler mit der aktuellsten Version des Produkts arbeiten und gleichzeitig Funktionen implementieren, an denen sie gerade arbeiten, um Probleme, die sich aus den Aktivit\u00e4ten anderer Entwickler ergeben, so fr\u00fch wie m\u00f6glich zu erkennen. <\/p>\n
Beim Versuch, Funktionen verschiedener Snapshots zu kombinieren (was einfach das Finden des gemeinsamen Vorfahren und das schrittweise Anwenden der Changesets, die sie erzeugt haben, aufeinander bedeutet, wird diese Operation als Rebase bezeichnet; das Zusammenf\u00fchren hingegen \u2013 ist fast wie ein Rebase, strukturiert jedoch den Commit-Graphen anders, was ihn schwerer manipulierbar macht, weshalb man Zusammenf\u00fchrungen in der Regel zugunsten von Rebase vermeidet) treten Probleme auf. Moderne Versionskontrollsysteme (VCS) verwenden interne Algorithmen zur Zusammenf\u00fchrung von \u00c4nderungen, die einfach Dateien in einzelne Zeilen zerlegen, jede Zeile als Zeichen betrachten und die Dateien als Sequenzen behandeln, um dann Algorithmen zu verwenden, die aus der Bioinformatik stammen, um sie zusammenzuf\u00fchren. <\/p>\n
Leider hat diese zeilenweise Darstellung des Quellcodes nichts mit seinem Inhalt zu tun. Ihre einzige St\u00e4rke liegt in der Einfachheit und Universalit\u00e4t. Diese Inkonsistenzen f\u00fchren zu Konflikten und sind eine st\u00e4ndige Quelle von Kopfschmerzen f\u00fcr Entwickler. Das L\u00f6sen von Konflikten erfordert, dass Entwickler beide Versionen des Codes sorgf\u00e4ltig pr\u00fcfen, nicht nur die Abschnitte, die durch den zeilenweisen Vergleichsalgorithmus als \"ge\u00e4ndert\" oder \"konfliktbehaftet\" gekennzeichnet sind, sondern m\u00f6glicherweise das gesamte Projekt. <\/p>\n
Der Entwickler muss die \u00c4nderungen verstehen, den zusammengef\u00fchrten Code manuell schreiben und alle Inkonsistenzen beseitigen. Die Probleme multiplizieren sich, wenn das zeilenweise Werkzeug \u00c4nderungen falsch identifiziert, was h\u00e4ufig bei gr\u00f6\u00dferen \u00c4nderungen passiert, einschlie\u00dflich trivialer Dinge wie der Formatierung des Codes. Wenn nachfolgende \u00c4nderungen nicht auf den manuell zusammengef\u00fchrten Code angewendet werden k\u00f6nnen, wird die Situation zu einem v\u00f6lligen Albtraum. Trotz dieser erschreckenden F\u00e4lle funktioniert der zeilenweise Algorithmus in den meisten F\u00e4llen gut, insbesondere wenn Entwickler aktiv versuchen, keine Probleme zu verursachen. Eine M\u00f6glichkeit, solche Probleme zu minimieren, ist die zwingende Anforderung der Verarbeitung von Quellcodes durch Kanonalisierungswerkzeuge wie black. <\/p>\n
Die einzig richtige L\u00f6sung f\u00fcr solche erschreckenden F\u00e4lle (und grunds\u00e4tzlich, nicht nur f\u00fcr sie, denn der zeilenweise Algorithmus ist eine Heuristik und kann einfach zu nicht funktionsf\u00e4higem Code f\u00fchren\u2014zum Beispiel, wenn ein Entwickler eine Variable umbenennt, w\u00e4hrend ein anderer gleichzeitig einen neuen Codeabschnitt schreibt, der diese Variable verwendet. Es gibt keinen Konflikt beim Mergen\/Rebasen, aber das Ergebnis wird nicht funktionsf\u00e4hig) besteht darin, das richtige interne Modell zu verwenden. <\/p>\n
Obwohl seit etwa 30 Jahren in diesem Bereich geforscht wird und mehrere propriet\u00e4re kommerzielle Produkte entstanden sind, wurden diese Forschungen bis vor kurzem noch nicht in praktisch anwendbare Open-Source-Produkte umgesetzt. Der Gro\u00dfteil der FOSS-L\u00f6sungen begann in den fr\u00fchen 2010er Jahren zu entstehen und konzentrierte sich haupts\u00e4chlich auf die Programmiersprache Java. <\/p>\n
Die herausragendste freie Implementierung aus dieser Zeit, GumTree, wurde von einem Forscher mit akademischem Hintergrund entwickelt, ist in Java geschrieben, verf\u00fcgt \u00fcber eine eigene abstrakte interne Darstellung, die treesitter vorausgeht, und hat Backends, die sowohl auf treesitter basieren als auch auf anderen Werkzeugen zur Analyse des Quellcodes in abstrakte Darstellungen. Dieses System kann nur \u00c4nderungen generieren (in Form eines textuellen Ereignisprotokolls; es gibt auch eine API, die problemlos aus jeder Programmiersprache aufgerufen werden kann, die Bindungen zu Java besitzt) und visualisieren. Aber f\u00fcr das Zusammenf\u00fchren von \u00c4nderungen und das Anschauen der von ihm generierten Diff-Dateien ist es von Haus aus nicht anwendbar (wobei es wahrscheinlich ist, dass das Laden von Diffs \u00fcber die API realisiert werden kann). <\/p>\n
Eine j\u00fcngere und in der Praxis anwendbarere Implementierung, Difftastic, wurde in Rust geschrieben, basiert auf treesitter und konzentriert sich auf die Generierung von hervorgehobenen Diffs in der Konsole. Dieses System zielt auch darauf ab, Diffs zu visualisieren, ohne das Ziel zu verfolgen, \u00c4nderungen zusammenzuf\u00fchren oder Patches anzuwenden. <\/p>\n
Vor kurzem ist das Projekt mergiraf entstanden, das sich aktiv weiterentwickelt. Dieses in Rust geschriebene Tool (es belegt 21 MiB!) basiert ebenfalls auf treesitter, das f\u00fcr Parser kontextfreier Grammatiken in Entwicklungstools zum Standard geworden ist, genau wie LLVM f\u00fcr die Optimierung von Niedrig-Level-Anweisungen. Im Gegensatz zu seinen Mitbewerbern bietet mergiraf Funktionen zur automatischen Aufl\u00f6sung von Merge-Konflikten, nicht zur Generierung von Diffs. Unter der Haube verwendet mergiraf f\u00fcr die Patch-Generierung eine Implementierung des in GumTree verwendeten Algorithmus und f\u00fcr die Anwendung eine Implementierung des in spork verwendeten Algorithmus, die an die Strukturen von treesitter angepasst ist. <\/p>\n
Die Serialisierung von Patches in Dateien, die sp\u00e4ter angewendet werden k\u00f6nnen, ist leider nicht implementiert (es ist jedoch ganz wahrscheinlich, dass dies durch das Parsen von Ereignisprotokollen, die von GumTree generiert werden, realisiert werden kann). Eine weitere vielversprechende Methode zur Anwendung von Unterschieden k\u00f6nnte die Verwendung von Unterschieden \u00fcber Patches hinweg sein, sondern \u00fcber die Funktionalit\u00e4ten von LSP-Servern f\u00fcr Refactoring, was bei der Erkennung von Konflikten im gesamten Projekt helfen k\u00f6nnte. Die Visualisierung wird nur f\u00fcr Konflikte unterst\u00fctzt. <\/p>\n
Beispiel: gemeinsamer Vorfahr \"base.py\" (mit Tab-Einz\u00fcgen, \u00fcbersch\u00fcssiger Zeile zu Beginn) foo = 1 def main(): print(foo + 2 + 3) \"a.py\" (mit Tab-Einz\u00fcgen, 2 \u00fcbersch\u00fcssige Zeilen am Anfang anstelle von einer, f\u00fcr Debug-Ausgaben wird die icecream-Bibliothek verwendet, Klasse \"baz\" hinzugef\u00fcgt: from icecream import ic foo = 1 def main(): ic(foo + 2 + 3) class baz: def __init__(self): \"\"\"baz\"\"\" \"b.py\" (Variable \"foo\" in \"bar\" umbenannt, nach den \u00c4nderungen mit \"black\" bearbeitet, demzufolge sind die Einz\u00fcge \u2014 Leerzeichen und \u00fcbersch\u00fcssige Zeilen entfernt): bar = 1 def main(): print(bar + 2 + 3) Der Befehl .\/mergiraf merge .\/base.py .\/a.py .\/b.py -x a.py -y b.py -s base.py -o .\/res.py liefert folgendes Ergebnis from icecream import ic bar = 1 def main(): ic(bar + 2 + 3) class baz: def __init__(self): \"\"\"baz\"\"\" (F\u00fcr Debug-Ausgaben wird die Bibliothek \"icecream\" verwendet, die Variable \"foo\" wird in \"bar\" umbenannt, nach den \u00c4nderungen mit \"black\" bearbeitet, demzufolge sind die Einz\u00fcge \u2014 Leerzeichen und \u00fcbersch\u00fcssige Zeilen entfernt, Mischung aus Tabs und Leerzeichen f\u00fcr Einz\u00fcge, jedoch in zugelassenem Format). <\/p>\n