> ## Content Index > Fetch the complete content index at: https://modelllogik.de/llms.txt > Use this file to discover other available public pages before exploring further. # Git als gemeinsame Datenumgebung für IFC — ein Messbericht - URL: https://modelllogik.de/git-als-cde-der-messbericht/ - Published: 2026-09-10T14:12:14.000Z - Updated: 2026-09-14T13:34:04.000Z - Description: Ein CDE ist ein Prozess, kein Produkt — aber irgendetwas muss ihn tragen. Git ist der offene Kandidat. Zwei Messtage an einem Testmodell: was ein Text-Diff wirklich zählt, und was passiert, wenn zwei Bearbeiter dieselbe Wand verschieben. - Author: Andràs Marghescu - Tags: Fachartikel Eine gemeinsame Datenumgebung ist ein Prozess und kein Produkt. Das ist der Satz, mit dem jede Einführung in die ISO 19650 beginnt, und er stimmt. Er beantwortet nur nicht die Frage, die danach kommt: **Worauf lässt man diesen Prozess laufen, wenn das Projekt ein Einfamilienhaus ist und nicht ein Klinikum?** Für große Vorhaben gibt es CDE-Fachprodukte, und sie sind ihr Geld wert. Für ein kleines Büro, für eine Ausbildungsklasse, für ein Forschungsvorhaben sind sie weder bezahlbar noch nötig — und trotzdem sollen dort dieselben vier Container-Zustände, dieselben Freigaben und dieselbe Nachvollziehbarkeit gelten. Der offene Kandidat für diese Lücke heißt **Git**. Ich führe ihn in meinem Unterricht und in meinem Buchmanuskript als benannte Referenzumsetzung — und genau das war der Grund, ihn vorher auseinanderzunehmen. Eine Setzung, die man Lernenden hinstellt, sollte man selbst gefahren haben. **Gemessen habe ich deshalb nicht am Einfamilienhaus, an dem ich openBIM sonst durchgängig zeige, sondern an einem Wegwerf-Testhaus:** ein Rechteck mit vier benannten Wänden `W1` bis `W4`, einer Tür, einem Raum und einem Geschoss, dazu eine IDS mit zwei Anforderungen. Klein genug, dass ein Text-Diff noch von Hand zu lesen ist; strukturell vollständig genug, dass echte IFC-Mechanismen sichtbar werden. Wer die Zahlen weiter unten auf ein Modell mit 24.000 Objekten überträgt, überträgt sie zu weit. **Warum überhaupt eine eigene Messung?** Weil zu dieser Frage zwei Lager schreiben und keines Zahlen vorlegt. Das eine sagt, natives IFC in einer Versionsverwaltung funktioniere hervorragend; das andere sagt, IFC lasse sich nicht zusammenführen, und beruft sich auf globale Entitätsnummern. Beide Seiten argumentieren plausibel. Nachgerechnet hat es öffentlich kaum jemand — und was man nicht selbst gefahren hat, sollte man auch nicht in einen Abwicklungsplan schreiben. Der Fall, an dem sich das entscheidet, ist der einfachste, den eine gemeinsame Datenumgebung aushalten muss. **Zwei Bearbeiter verschieben dieselbe Wand.** Der eine um 500 Millimeter, der andere um 800\. Beide speichern, beide legen einen Commit an, einer führt die Zweige zusammen. Was steht danach im Modell? Die Antwort ist unspektakulärer, als beide Lager sie hätten — und darin liegt ihr Wert. **Das Werkzeug führt die beiden Änderungen nicht zusammen. Es meldet den Konflikt, vollständig und mit allen drei Werten, und legt die Entscheidung dorthin zurück, wo sie hingehört: zu den beiden Bearbeitern.** Nichts geht verloren, nichts wird still entschieden. Das ist weniger, als die Literatur verspricht, und erheblich mehr, als die deutschsprachige Praxis erwartet. Zwei Messtage stehen hinter diesem Text. Am **2026-08-11** ist der Versuch gefahren worden, an Bonsai und IfcOpenShell in der Fassung `0.8.6-alpha260724`. Am **2026-09-09** habe ich ihn am Repository gegengelesen und den Konfliktfall neu gefahren — an Blender 5.2.0 LTS, Bonsai 0.8.5, IfcOpenShell 0.8.5, git 2.55.0 und dem `ifcmerge` der veröffentlichten Fassung vom 2026-04-07, das Bonsai 0.8.5 beiliegt. ## Warum die Frage überhaupt offen ist Ein IFC-Modell ist eine Datei, und eine Datei hat einen Bearbeiter. Das ist keine Schwäche des Formats, sondern die Ordnung, auf die sich die Praxis geeinigt hat: Jedes Fachmodell gehört einer Disziplin, wird von ihr geliefert und für die Koordination **föderiert** — gemeinsam betrachtet, nicht zusammengeführt. Wer an einem fremden Fachmodell etwas geändert haben will, ändert es nicht. Er beschreibt die Änderung — als BCF-Vorgang, in einer Mail, in einer Besprechung — und wartet. Diese Ordnung hat einen guten Grund: Die Verantwortung bleibt dort, wo die Fachkunde sitzt. Sie hat auch einen Preis, und der wird selten benannt. Zwei Leute können nicht gleichzeitig an einem Fachmodell arbeiten, auch dann nicht, wenn der eine das Erdgeschoss und der andere den Dachstuhl bearbeitet. Der Rückweg von der Baustelle ins Modell führt über dieselbe Engstelle. Und Beziehungen über Modellgrenzen hinweg sind mühsam — Räume und Geschosse stehen im Architekturmodell, die Geräte, die man ihnen zuordnen möchte, im TGA-Modell. Warum lässt sich eine IFC-Datei nicht einfach zusammenführen wie zwei Fassungen eines Textes? Zwei Gründe werden dafür genannt. Der eine ist das Format: Eine IFC-Datei im STEP-Format *ist* Text, aber ihre Zeilen tragen Nummern — `#18`, `#35`, `#119` —, und diese Nummern sind über die ganze Datei hinweg eindeutig. Wird eine geschrieben, können sich alle verschieben. Ein zeilenweiser Vergleich sieht dann Bewegung, wo fachlich nichts passiert ist. Der andere Grund ist das Werkzeug: Die verbreiteten BIM-Anwendungen halten ihr Modell in einem eigenen Format und **exportieren** IFC. Was exportiert wird, ist jedes Mal eine neu geschriebene Datei — und jeder Weg zurück kostet Information. **Git** setzt an dieser Stelle an, und es kommt nicht aus dem Bauwesen. Es ist die Versionsverwaltung, mit der Software geschrieben wird: Sie hält jede Fassung jeder Datei fest, mit Urheber, Zeitpunkt und einer Nachricht, die sagt, was der Stand ist. Man arbeitet auf einem **Zweig** neben dem Hauptstand, hält Zwischenstände als **Commit** fest, beantragt die Übernahme als **Pull Request**, lässt prüfen, **mergt**, und markiert Meilensteine mit einem **Tag**. Wer die vier Zustände der ISO 19650 daneben legt, sieht die Entsprechung sofort — Arbeitszweig, Prüfantrag, Hauptstand, Historie. **Das ist der Grund, warum Git für diese Lücke überhaupt in Frage kommt: Es bringt die Mechanik mit, die ein CDE organisatorisch verlangt, ohne eine CDE-Plattform zu sein.** Der Kern heißt **Drei-Wege-Merge**. Er fragt nicht, wer zuletzt gespeichert hat. Er nimmt den gemeinsamen Ausgangsstand als Bezug und fragt: Was hat der eine daran geändert, was der andere — und lässt sich beides übernehmen? Für IFC braucht dieser Vergleich ein Werkzeug, das Entitäten statt Zeilen betrachtet: **`ifcmerge`**, von Bruno Postle, auf der Kommandozeile. Und er braucht eine Voraussetzung auf der Schreibseite: Das Autorenwerkzeug muss die IFC-Datei **bearbeiten**, nicht importieren und exportieren. **Bonsai** — die IFC-Erweiterung für Blender, bis 2024 BlenderBIM — tut das; das geöffnete Modell *ist* die IFC-Datei. Damit steht die Kette da: **Bonsai schreibt, Git verwaltet, `ifcmerge` führt zusammen.** Was dieser Text misst, ist diese Kette und keine andere. ## Die These, wie sie in der Literatur steht Bruno Postle hat die Frage 2022 in einem Whitepaper beantwortet, das `ifcmerge` beiliegt und den Begriff *Native IFC* geprägt hat: Bruno Postle, mit Ergänzungen von Dion Moult, *Native IFC. A white-paper introducing a collaborative BIM using open standards and open protocols*, `github.com/brunopostle/ifcmerge/blob/main/docs/whitepaper.rst`. Die These ist weitreichend, und sie ist es ausdrücklich. Wenn eine Anwendung IFC-Daten unmittelbar bearbeitet, bleiben die Änderungen an einer Datei klein — beschränkt auf das, was tatsächlich geändert, gelöscht oder ergänzt wurde. Auf dieser Grundlage lasse sich Git als gemeinsame Datenumgebung für Bauwerksmodelle betreiben, skalierbar, sicher, zukunftsfest. **Man sollte kurz stehen bleiben und würdigen, was für ein Einfall das ist.** Das Bauwesen hat zwei Jahrzehnte damit zugebracht, Zusammenarbeit dadurch zu lösen, dass es sie **verhindert**: Server mit Ein- und Auschecken, Sperren auf Dateien und Bauteilen, Fachmodelle in getrennten Händen, Föderation als Königsweg. Jede dieser Antworten läuft darauf hinaus, dass zwei Menschen nicht gleichzeitig dasselbe anfassen dürfen. Postles Vorschlag dreht das um: **Verhindere den Konflikt nicht, löse ihn hinterher auf.** Und zwar mit derselben Technik, ohne die verteilte Softwareentwicklung nie entstanden wäre — dem Drei-Wege-Merge. Das Bemerkenswerte daran ist, wie **wenig** dafür nötig ist. Kein neues Format, kein neuer Server, kein Konsortium, kein Gremium. Die Voraussetzung, die das Papier formuliert, sind drei Regeln darüber, wie eine Anwendung eine Datei zurückschreibt — und wer sie einhält, hat immer noch eine ganz gewöhnliche, normkonforme IFC-Datei, die jedes ältere Werkzeug lesen kann. Dazu kommt alles, was die Softwarewelt in dreißig Jahren um Git herum gebaut hat: die Historie, die Urheberschaft jeder Änderung, Freigaben, Vorgangssysteme, automatische Prüfläufe bei jedem Stand. Nichts davon muss die Baubranche noch einmal erfinden. **Und es ist nicht bei der Idee geblieben.** Postle hat die Referenzumsetzung geschrieben, unter die GPL gestellt und seit 2022 gepflegt — `ifcmerge`, das Werkzeug, das dieser Text auf Herz und Nieren prüft. Ein Vorschlag, der sein eigenes Werkzeug mitbringt, ist etwas anderes als ein Vorschlag. Er ist überprüfbar. *Und genau deshalb wird er hier überprüft. Wer eine gute Idee ernst nimmt, misst sie nach — nicht, um sie zu erledigen, sondern um zu wissen, wo ihre Kanten sind.* Das Papier nennt die Bedingungen. Eine Anwendung gilt ihm nur dann als *Native IFC*, wenn sie drei Regeln einhält: Entitäten werden in dem Format zurückgeschrieben, in dem sie gelesen wurden, mit denselben Nummern; Attributänderungen werden an Ort und Stelle geschrieben, unter Erhalt der Entitätsnummer; und die Nummern gelöschter Entitäten werden nicht wiederverwendet. **Als Anwendungen, die das bereits tun, führt es unter anderem BlenderBIM und IfcOpenShell** — die Bibliothek, auf der Bonsai aufsetzt und über die auch das Testskript dieses Berichts schreibt. Das ist weiter unten wichtig. Das Zusammenführen beschreibt das Papier präzise genug, um es prüfen zu können. Entitäten, die in beiden Zweigen hinzugekommen sind, werden umnummeriert. Wurden in beiden Zweigen *verschiedene* Attribute derselben Entität geändert, lassen sich beide Änderungen übernehmen. Wurde eine Entität im einen Zweig gelöscht und im anderen geändert, bricht das Zusammenführen ab. Das ist keine Werbeschrift; das Papier benennt eigene Grenzen — Föderation bleibt für große Dateien nötig, und das Umnummerieren beim Zusammenführen verwischt die Zuordnung einzelner Commits. Dem gegenüber steht die Erwartung, die in der deutschsprachigen BIM-Praxis verbreitet ist und die ich selbst aufgeschrieben hatte: IFC sei zwar Text, die Nummern aber global, ein Zusammenführen erzeuge deshalb unlesbare Unterschiede und laufende Konflikte. Zwischen beidem liegt eine Messung. ## Der Aufbau **Das Repository.** Ein privates Test-Repository auf GitHub, dessen Ordnerstruktur die vier Container-Zustände sichtbar macht: `01_WIP/`, `02_SHARED/`, `03_PUBLISHED/`, `04_ARCHIVE/`, dazu `BCF/`, `GIS/`, `DOCS/`. Es bleibt privat; eine Adresse steht deshalb in diesem Text nicht. **Der Prüfkörper.** Vier benannte Wände, eine Tür, ein Raum, ein Geschoss, IFC4, Längeneinheit Millimeter. Er liegt in `03_PUBLISHED/` und trägt das Meilenstein-Tag `v1.0-M2`. **Die Rollen.** Rollenspiel mit zwei Konten: eine Fachplaner-Rolle ändert, eine Koordinations-Rolle prüft und gibt frei. Auf `main` verlangt eine Branch-Protection einen Pull Request und mindestens eine Freigabe. **Die Änderung.** Ein Zweig `arc/waende-korrigieren`, darauf die Wand `W1` um 500 Millimeter verschoben; parallel die IDS verschärft, die Kardinalität für `IsExternal` von *optional* auf *required*. Ein Koordinationsvorgang „Wand W1 kollidiert mit Türöffnung" doppelt geführt, als GitHub-Issue und als BCF-Containerdatei. **Die zwei Schreibwege.** Ein eigenes Python-Skript über die IfcOpenShell-Programmierschnittstelle — und Bonsai selbst: dieselbe Wand im Viewport greifen, verschieben, `Strg+S`. **Der Konfliktfall.** Ein zweiter Zweig verschiebt dieselbe Wand `W1` abweichend um 800 Millimeter. Beide Zweige gehen von einem Stand aus, in dem die Arbeitsdatei bereits vorliegt — der Fall also, um den es in einem Projekt wirklich geht: **zwei Bearbeiter ändern eine Datei, die es schon gibt.** **Der zweite Messtag.** Am 2026-09-09 habe ich diesen Konfliktfall in einem eigenen Arbeitsbaum (`git worktree`) nachgestellt, damit der Hauptstand unberührt bleibt, und dabei jeden Schritt protokolliert — Konfliktstufen, Rückgabewerte, Ausgaben im Wortlaut. ## Die Messungen **Der Bonsai-Save, 2026-08-11.** Eine Wandverschiebung um 500 Millimeter, in der Oberfläche gemacht und nativ gespeichert, ändert **14 Zeilen**: sieben verschwinden, sieben kommen dazu. Zwei davon sind der Dateikopf — Zeitstempel und Werkzeugvermerk. Zwei betreffen das Wandobjekt selbst: Es behält seine `GlobalId` und alle Attribute, nur der Verweis auf seine Verortung wandert von `#35` auf `#119`. Die restlichen zehn sind der Verortungs-Teilgraph, fünf alte Entitäten weg, fünf neue dazu. **Alles andere in der Datei ist bitgleich** — die Eigenschaftsmenge, die Geometrie, die räumliche Einordnung, die drei übrigen Wände. Genau dieses Verhalten beschreibt das Whitepaper. Bonsai ändert den Verortungs-Teilgraphen nicht an Ort und Stelle, sondern verwirft ihn und legt ihn neu an — für mehrdeutige Teilgraphen lässt das Papier genau das ausdrücklich zu. **Dieselbe Verschiebung über die Programmierschnittstelle, 2026-09-09.** Wieder die Wand `W1`, wieder um 500 Millimeter — diesmal nicht in der Oberfläche gegriffen, sondern über das Python-Skript. Das Skript ändert **zwei Zeilen weg, fünf dazu**. Aufgeschlüsselt: eine Zeile ist die Koordinate. Drei sind eine Eigenschaftsmenge, die das Testskript als Marker schreibt und die Bonsai gar nicht anlegt. Und eine hat niemand geändert — beim Neuschreiben wird aus `1.E-05` die Zahl `1.0000000000000001E-05`, dieselbe Gleitkommazahl in anderer Schreibweise. **Die eigentliche Änderung sind zwei Zeilen.** Die Entitätsnummern bleiben sämtlich stehen. **Wie steht der Schreibweg damit da?** Ordentlich verglichen — dieselbe Verschiebung, beide Male an einer Datei, die schon vorhanden war: | | Bonsai-Save | Skript über die Schnittstelle | | --------------------------------- | ------------- | -------------------------------------------------------- | | ganzer Diff | 14 Zeilen | 7 Zeilen | | davon die Wandverschiebung selbst | 12 | 2 | | davon anderes | 2 (Dateikopf) | 5 (Marker-Pset des Testskripts, Fließkomma-Schreibweise) | **Bonsai schreibt in beiden Rechnungen mehr** — weil es den Dateikopf erneuert und den Verortungs-Teilgraphen verwirft und neu anlegt, statt die Koordinate an Ort und Stelle zu ändern. Beides ist erlaubt, beides ist Native IFC: **IfcOpenShell, die Bibliothek hinter dem Skript, steht im Whitepaper selbst auf der Liste der Anwendungen, die den Standard bereits erfüllen.** Der Schreibweg ist also nicht die Trennlinie, für die man ihn hält. **Woher der Unterschied in einem Diff kommt.** Ein Text-Diff zählt Zeilen, keine Bedeutungen — und was er zählt, hängt davon ab, was ihm vorgelegt wird. Wird eine Datei **geändert**, zeigt er die Zeilen, die sich unterscheiden: hier zwei. Wird dieselbe Datei dagegen **neu angelegt** — weil ein Meilenstein seine eigene Arbeitsdatei bekommt —, zählt derselbe Diff die ganze Datei als hinzugefügt: bei unserem Prüfkörper **116 Zeilen**, für genau dieselbe Wandverschiebung. Die Anzeige ist in beiden Fällen richtig; sie beantwortet nur eine andere Frage, als man ihr stellt. **Zwei und 116 beschreiben denselben Vorgang.** Wer eine Zahl aus einer Diff-Ansicht übernimmt, muss deshalb wissen, ob sie einen Unterschied misst oder einen Bestand — und das steht nicht daneben. **Der semantische Vergleich.** Derselbe Vorgang, nicht zeilenweise, sondern nach Entität und Eigenschaft ausgewertet, ergibt **eine** Änderung: die Wand `W1`, Verortung und Eigenschaftsmenge. Zum Vergleich schlägt die Änderung an der IDS — eine Kardinalität — mit rund vier Zeilen zu Buche. **Die Einheitenfalle.** Beim ersten Durchlauf steckte im Skript ein Fehler: Es rechnete mit Metern, das Modell speichert in Millimetern. Die Wand verschob sich statt um 500 Millimeter um 0,5 — in Bonsai nicht wahrnehmbar. Die Korrektur steckt als eigener Commit in der Historie, und ihr Diff ist **drei Zeilen**. **Drei Zeilen für eine Verwechslung um den Faktor 1000\. Drei Zeilen für die richtige Änderung.** Der Text-Diff kann die beiden nicht unterscheiden. Er sagt zuverlässig, *dass* sich etwas geändert hat, und nichts darüber, ob es das Richtige war. Ein Neu-Nummerieren der ganzen Datei, das man an dieser Stelle vermuten könnte, findet dabei nicht statt: Die Entitätsnummern bleiben in allen gemessenen Fällen stehen. ![Vier gleich grosse Karten nebeneinander, alle zum selben Vorgang: eine Wand um 500 Millimeter verschoben. Erste Karte „Bonsai, nativ gespeichert": gross die Zahl 14, darunter „Zeilen im Diff" und der Zusatz, dass davon zwölf die Verschiebung selbst betreffen. Zweite Karte „Skript über die Schnittstelle": die Zahl 7, darunter „Zeilen im Diff" und der Zusatz, dass davon zwei die Verschiebung selbst betreffen. Dritte Karte „Dieselbe Änderung, Datei neu angelegt": die Zahl 116, darunter „Zeilen im Diff" und der Zusatz, dass das die ganze Datei ist und nicht der Unterschied. Vierte Karte, beige getönt und orange gerahmt, „Semantischer Vergleich": die Zahl 1, darunter „Änderung" und der Zusatz „Wand W1, Verortung und Eigenschaftsmenge". Unter den Karten ein getöntes Band über die volle Breite: Alle vier Zahlen beschreiben denselben Vorgang. Der Diff zählt Zeilen; was sich fachlich geändert hat, sagt nur der semantische Vergleich.](https://storage.ghost.io/c/df/a1/dfa16b2e-2024-4a5f-866f-818cf6baf53a/content/images/2026/09/t1-1_was_der_diff_zaehlt-1.png) Dreimal derselbe Blick auf denselben Prüfkörper — und dreimal eine andere Zahl. Der Text-Diff sagt zuverlässig, dass sich etwas geändert hat. Was sich geändert hat, sagt erst der semantische Vergleich. **Der Konfliktfall.** Und nun der Vorgang, um den es einer Koordination wirklich geht: dieselbe Wand, zwei Bearbeiter, 500 gegen 800 Millimeter, beide Änderungen an einer Datei, die es im gemeinsamen Ausgangsstand schon gibt. Git meldet einen Konflikt am Inhalt und legt alle drei Stände nebeneinander: Basis, lokale und entfernte Fassung. `ifcmerge` **scheitert daran sauber** — Rückgabewert 1, die Datei bleibt als ungelöst markiert, die Konfliktmarken bleiben stehen. Und es legt einen vollständigen Bericht ab: Konflikttyp, Entitätsklasse `IFCCARTESIANPOINT`, Entitätsnummer, der Wert der Basis `(0.,0.,0.)`, der lokale `(0.,800.,0.)`, der entfernte `(0.,500.,0.)`, und welchen es gewählt *hätte*. **Nichts wird verworfen. Nichts geschieht still.** Das Werkzeug tut genau das, was man von ihm erwarten darf: Es sagt, wo der Widerspruch sitzt, und rührt ihn nicht an. **Und dann?** Der Merge hält an, das Projekt nicht. Was jetzt folgt, ist kein technischer, sondern ein organisatorischer Schritt: **Die BIM-Koordination entscheidet, welcher Wert gilt** — 500 oder 800\. Der unterlegene Zweig verwirft seine Fassung, und erst der geklärte Stand wird zusammengeführt. Auf dem Hauptzweig entsteht daraus ein neuer verbindlicher Stand, mit Meilenstein-Tag; in der Sprache der ISO 19650 ist das der Übergang nach *Published*. **Das Werkzeug hat den Widerspruch sichtbar gemacht. Freigegeben wird er von einer Person mit Namen.** ![Oben drei gleich grosse Dateiblätter mit abgeschnittener Ecke nebeneinander. Das linke ist mit „Basis" überschrieben, Zusatz „der gemeinsame Ausgangsstand", darunter der Wert W1 bei 0 mm. Das mittlere ist mit „lokal" überschrieben, Zusatz „der Zweig, auf dem gemergt wird", Wert W1 bei 800 mm. Das rechte ist mit „entfernt" überschrieben, Zusatz „der Zweig, der hereinkommt", Wert W1 bei 500 mm. Von allen dreien führen Linien nach unten in einen abgerundeten Kasten „git merge, dann ifcmerge". Von dort ein Pfeil in ein grosses, beige getöntes und orange gerahmtes Feld mit der Überschrift „Konflikt gemeldet, Rückgabewert 1". Darin die Angaben des Berichts: IFCCARTESIANPOINT, Entität Nummer 31, Basis null, lokal 800, entfernt 500; darunter, dass die Datei als ungelöst markiert bleibt und dass nichts überschrieben und nichts verworfen wird. Von diesem Feld führt ein dunkler Pfeil weiter nach unten in einen weissen, kräftig gerahmten Kasten „Die BIM-Koordination entscheidet": Der unterlegene Zweig verwirft seine Fassung, der geklärte Stand wird gemergt und getaggt — er ist der neue Hauptstand. Ganz unten ein getöntes Band: Zusammengeführt wird, was sich nicht widerspricht; über den Widerspruch entscheidet ein Mensch.](https://storage.ghost.io/c/df/a1/dfa16b2e-2024-4a5f-866f-818cf6baf53a/content/images/2026/09/t1-2_drei_staende_ein_konflikt-1.png) Der Drei-Wege-Merge vergleicht drei Stände, und ihre Namen stehen an den Kästen: Basis, lokal, entfernt. Widersprechen sich lokal und entfernt an derselben Entität, führt ifcmerge nicht zusammen — es legt alle drei Werte offen und hält an. **Warum der viel gerühmte Auto-Resolve dabei gar nicht auftaucht**, ist der lehrreichste Einzelbefund. Er ist ausdrücklich auf Konflikte an der Verortungsentität beschränkt. Das Skript ändert aber die **Koordinate** an Ort und Stelle — der Konflikt wird deshalb als Attributkonflikt an einem kartesischen Punkt eingestuft, und für den gilt die Ausnahme nicht. Bonsai dagegen verwirft den Verortungs-Teilgraphen und legt ihn neu an; dort *wäre* es ein Verortungskonflikt. **Der Schreibweg entscheidet, ob der Auto-Resolve überhaupt zuständig ist.** **Und eine Randnotiz mit Folgen.** `ifcmerge` liegt Bonsai 0.8.5 bei — die beiliegende Programmdatei ist byteweise identisch mit der veröffentlichten Fassung vom 2026-04-07\. Im dauerhaften Suchpfad des Rechners steht sie jedoch nicht, weder für den Benutzer noch für das System; auffindbar ist sie nur, weil Bonsai den Suchpfad zur Laufzeit ergänzt. Mit bereinigter Umgebung nachgestellt, meldet derselbe Aufruf schlicht `ifcmerge: command not found`. Der Merge scheitert dann — folgenlos, aber er läuft eben nicht. ## Der Befund, der gegen die eigene These arbeitet Es sind drei. **Der Schreibweg ist nicht der Unterschied, für den ich ihn gehalten habe.** Die Erwartung, mit der ich angefangen habe, war: Wer über eine Programmierschnittstelle schreibt, erzeugt Rauschen; wer nativ in der Oberfläche speichert, erzeugt einen lesbaren Diff. Gemessen ist beides derselbe Mechanismus — beide Wege erhalten die Entitätsnummern, beide stehen im Whitepaper auf derselben Liste. **Ein Kriterium, nach dem man Werkzeuge auswählen möchte, trägt damit nicht.** Was den Diff wirklich groß macht, ist nicht die Schnittstelle, sondern ob eine Datei geändert oder neu angelegt wird. **Und der Merge löst genau den Fall nicht, für den man ihn haben will.** Zwei Leute, dieselbe Wand, zwei Werte — das ist der Vorgang, wegen dem man sich für einen Drei-Wege-Merge interessiert. Er wird nicht aufgelöst, er wird gemeldet. Das ist die richtige Entscheidung des Werkzeugs, und es ist trotzdem weniger, als das Versprechen „paralleles Arbeiten am selben Modell" nahelegt. **Zusammengeführt wird, was sich nicht widerspricht.** Wo es sich widerspricht, sitzen weiterhin zwei Menschen und müssen reden — und die Verabredung darüber, wer in so einem Fall nachgibt, ersetzt kein Werkzeug. **Und die Spur, wer was geändert hat, wird beim Zusammenführen unschärfer.** Das ist der dritte Punkt, und er stammt nicht aus meiner Messung, sondern aus dem Whitepaper selbst — dort steht er als eingeräumte Grenze, und er wird selten mitzitiert. Der Reiz einer Versionsverwaltung liegt ja gerade darin, dass sie diese Frage beantwortet: Jeder Commit trägt einen Namen, einen Zeitpunkt und eine Begründung, und deshalb lässt sich zu jeder Änderung sagen, wer sie gemacht hat. **Beim Zusammenführen bleibt davon weniger übrig, als man denkt.** Weil `ifcmerge` Entitätsnummern umschreiben muss, damit sich zwei Zweige nicht ins Gehege kommen, ist das Ergebnis nicht einfach die Summe der beiden Ursprungsdateien, sondern eine neu geschriebene. Das Papier beschreibt die Folge so: Der Vorgang verwischt die feine Unterscheidung zwischen den einzelnen Commits, und in einem Ablauf mit Pull Requests und Freigaben landen die Änderungen bei **der zuletzt freigebenden Stelle**. Wer die Urheberschaft erhalten will, muss sie von Hand in die Commit-Nachricht schreiben. **Für ein Bauprojekt ist das kein Randdetail.** „Wer hat die Wand verschoben?" ist dort keine akademische Frage, sondern die, an der Verantwortung hängt — und im Zweifel Geld. Eine Historie, die an dieser Stelle auf die Koordination zeigt statt auf den Fachplaner, der die Wand tatsächlich bewegt hat, trägt weniger weit, als das Wort *Nachvollziehbarkeit* verspricht. **Nachgemessen habe ich das nicht.** Es steht so im Papier, es ist plausibel, und es gehört auf die Liste der Dinge, die man wissen sollte, bevor man eine Historie als Nachweis anbietet. ## Die Grenzen Der Prüfkörper war ein Wegwerf-Testhaus mit vier Wänden, einer Tür und einem Raum. Über das Verhalten großer Modelle sagt diese Messung nichts. Das Whitepaper führt dafür eigene Beispiele an — sechsstellige Entitätszahlen, ein Zusammenführen in Sekunden; das sind fremde Messungen an fremden Modellen. Gemessen wurde **ein** Fachmodell, in **einer** Disziplin, auf **zwei** Zweigen, von **einer** Person in zwei Rollen. **Die 14 Zeilen des Bonsai-Save sind nicht nachgemessen.** Sie stammen vom 2026-08-11 und von der unstabilen Fassung `0.8.6-alpha260724`; auf dem Rechner läuft inzwischen die stabile 0.8.5\. Der Wert ist am aufgezeichneten Diff belegt, aber er ist älter als die übrigen. **Und die wichtigste offene Stelle:** Der Konfliktlauf hat die Änderung über das Skript erzeugt. **Ob `ifcmerge` den Konflikt auflöst, wenn beide Fassungen in Bonsai gespeichert wurden**, ist damit nicht beantwortet — denn nur dort entsteht überhaupt ein Verortungskonflikt, und nur für den gilt die Ausnahme. Es kann also gut sein, dass der Auto-Resolve im Bonsai-Weg greift und die abweichende Änderung übergeht. Das ist zu messen, nicht zu vermuten, und es ist nicht gemessen. Die Zahlen hängen am Schreibweg und an der Werkzeugfassung, nicht am Format. Sie sind kein Urteil über IFC und keines über Git. ## Was daraus für die Praxis folgt Vier Punkte, die sich in einen BIM-Abwicklungsplan oder eine Werkzeugliste übersetzen lassen. **Die Modelleinheit gehört ausdrücklich in die Formatkonvention.** Nicht als Erwartung an eine Voreinstellung. Die Verwechslung um den Faktor 1000 erzeugt denselben Diff-Umfang wie die richtige Änderung; niemand sieht sie im Vorbeigehen. Eine Prüfregel, die Einheiten mitprüft, ist billiger als der Fehler. **Wer bei einem Widerspruch entscheidet, gehört in den Abwicklungsplan — nicht ins Werkzeug.** Der Merge meldet den Konflikt und hält an; entschieden wird von der **BIM-Koordination**, und zwar namentlich benannt. Der kurze Ablauf, der das ordnet: BCF-Vorgang öffnen, Wert klären, die unterlegene Seite verwirft ihre Fassung vor dem Merge. Erst der geklärte Stand geht in den Hauptzweig und bekommt sein Meilenstein-Tag — **die Freigabe ist ein Vorgang mit Urheber, kein Rückgabewert.** **Wo diese Verabredung fehlt, hilft kein Drei-Wege-Merge**, und wo sie steht, braucht man ihn selten. **`ifcmerge` gehört auf die Werkzeugliste — aber sehen Sie nach, was Sie schon haben.** Bonsai 0.8.5 bringt es mit; der Ladeschritt aus älteren Anleitungen ist überflüssig geworden. Der Eintrag im Suchpfad ist es nicht: Wer außerhalb von Bonsai mergt, findet das Werkzeug sonst nicht. **Der Text-Diff ist kein Prüfmittel.** Er beantwortet, *ob* sich etwas geändert hat, und das zuverlässig. Was sich geändert hat, beantwortet er nicht. Für die Prüfung bleiben die Mittel, die dafür gebaut sind: die farbliche Gegenüberstellung zweier Revisionen in Bonsai, der semantische Vergleich, und für die Anforderungsseite die IDS. ## Wie es weitergeht Trägt Git also ein CDE für kleine Vorhaben? **Ja — und zwar unspektakulärer, als beide Lager es erwarten.** Die Mechanik stimmt: Zustände, Freigaben, Historie — und, mit dem Vorbehalt von oben, auch die Frage, wer was geändert hat. Der Diff eines nativ geschriebenen Modells ist lesbar, das Argument der globalen Entitätsnummern trifft ihn nicht. Und wo zwei Änderungen sich widersprechen, hält das Werkzeug an und sagt genau, wo — was das Beste ist, was es tun kann. Die offene Stelle ist der Bonsai-Schreibweg im Konfliktfall, und sie ist die interessanteste von allen: Genau dort könnte der Auto-Resolve greifen, den der Skriptweg nie erreicht. Sie braucht die Oberfläche — zweimal dieselbe Wand verschieden verschieben, jeweils nativ speichern, committen, mergen. Der Arbeitsbaum dafür liegt bereit. Und die Fälle, die diese Messung nicht berührt hat, bleiben offen: mehrere Fachmodelle, mehrere Werkzeuge auf beiden Seiten, Modelle in einer Größe, bei der die Lesbarkeit eines Diffs keine Rolle mehr spielt. Wer dazu Zahlen hat, hat mehr als ich. Was bleibt, ist eine Antwort auf die Ausgangsfrage, und sie ist nüchterner, als beide Lager sie hätten. Zwei Bearbeiter verschieben dieselbe Wand, einer führt zusammen. Danach steht im Modell nichts Falsches — aber auch nichts Entschiedenes. **Die Versionsverwaltung nimmt einem die Buchführung ab. Die Abstimmung nimmt sie einem nicht.**