Zwei Codebasen zusammenführen: Eine Quelle der Wahrheit wählen und sauber migrieren

Warum zwei von AI gebaute Codebasen schnell zum Problem werden

Zwei AI-Tools können an einem Wochenende zwei sehr unterschiedliche Versionen derselben App erzeugen. Vielleicht haben Sie aus Geschwindigkeit mit einer v0 begonnen und dann in Replit neu gebaut, als es unordentlich wurde. Oder ein Kollege hat Lovable oder Bolt ausprobiert und ein paar Screens dort „repariert“. Jedes Repo kann für sich plausibel aussehen, sodass es verlockend ist, beide zu behalten und das später zu klären.

Hier beginnt die Arbeit. Prototypen weichen schnell voneinander ab. Die UI mag ähnlich aussehen, aber die Logik darunter ist oft anders. Ein Repo speichert Rollen in einer Tabelle, das andere in einem JSON-Blob. Das eine geht von E-Mail-Login aus, das andere von OAuth. Eine Woche später haben Sie nicht nur zwei Codebasen — Sie haben zwei Annahmesets.

Gängige Fehlermodi tauchen schnell auf:

• Der gleiche Bug existiert zweimal, aber mit unterschiedlichen Symptomen.
• Geschäftsregeln widersprechen sich (Preise, Berechtigungen, Statusregeln), sodass „korrekt" davon abhängt, welches Repo läuft.
• Datenmodelle driftet auseinander, was Migrationen riskant und Reporting unzuverlässig macht.
• Sicherheitsfixes landen nur an einem Ort, das andere bleibt zur Falle.

Der Versuch, zwei Codebasen Zeile für Zeile zusammenzuführen, macht es meist schlimmer. Am Ende fügen Sie unpassende Muster zusammen, übernehmen gebrochene Auth-Flows und ziehen unsichere Abfragen oder geleakte Secrets aus dem schwächeren Repo. Das Ergebnis ist eine dritte Codebasis, die schwerer zu verstehen ist als die beiden Originale.

Ein gutes Ergebnis ist einfach: eine Quelle-der-Wahrheit-Codebasis, ein Bereitstellungspfad und ein Ort, um Bugs zu beheben. Gute Ideen aus dem anderen Repo können wiederverwendet werden, aber nur durch gezielte Migration von Features. Das Ziel ist nicht „alles kombinieren“, sondern „eine vertrauen und nur das bewegen, was Sie verifizieren können."

Was „Quelle der Wahrheit" bedeutet (und was nicht)

Eine Quelle-der-Wahrheit-Codebasis ist der einzige Ort, an dem neue Änderungen landen dürfen. Wenn ein Feature ausgeliefert wird, geschieht das von dort. Wenn ein Bug behoben wird, geht die Korrektur dorthin. Alles andere wird zu Referenzmaterial, nicht zu einem zweiten Live-Produkt.

Das heißt nicht, dass das gewählte Repo perfekt, sauber oder zwingend Ihr Lieblingsrepo sein muss. Es bedeutet auch nicht, dass Sie das andere Repo am ersten Tag löschen. Sie können es für Vergleiche behalten oder nutzen, um zu verstehen, was Nutzer erwarten. Der Unterschied ist Governance: Nur ein Repo macht Fortschritte.

Bevor Sie wählen, definieren Sie, was „Wahrheit" abdeckt, damit Sie später keine Diskussionen haben. Halten Sie es klar:

• Produktverhalten (Features und wichtige UX-Flows)
• Datenmodell und Migrationen
• Authentifizierung und Berechtigungen
• Deployment-Setup und Umgebungs-Konfiguration
• Logging und Fehlerbehandlung

Dann setzen Sie eine Regel, der alle folgen: Das gewinnende Repo ist der einzige beschreibbare Pfad. Das andere wird schreibgeschützt und bleibt so.

Setzen Sie auch eine Entscheidungsfrist. AI-generierte Prototypen driften schnell, vor allem wenn zwei Tools weiter neue Dateien erzeugen. Ein praktisches Ziel sind 24 bis 72 Stunden: eines wählen, das andere einfrieren, dann gezielt migrieren. Wenn Sie unsicher sind, welches Repo sicherer ist, kann ein kurzer Audit frühe Hochrisiko-Probleme aufdecken, insbesondere rund um Auth, Secrets und Datenbank-Schreibzugriffe.

Ein schneller Vergleich zweier Codebasen ohne tiefes Fachwissen

Wenn Sie zwei Codebasen zusammenführen müssen, beginnen Sie nicht damit, zu debattieren, welches „schöner" aussieht. Prüfen Sie stattdessen, welches sich wie echte Software unter Basisdruck verhält: ausführen, bauen, bereitstellen und auf vorhersehbare Weise fehlschlagen.

Eine einfache Checkliste erzwingt einen fairen Vergleich. Geben Sie jedem Repo eine 0–2-Punkteskala (0 = fällt durch, 1 = wackelig, 2 = solide) für:

• Läuft lokal nach sauberer Installation (ohne geheime manuelle Schritte)
• Lässt sich reproduzierbar bauen und bereitstellen
• Hat mindestens ein paar sinnvolle Tests (oder Sie können sie schnell hinzufügen)
• Vermeidet Hacks (fest codierte URLs, kopierte Konfiguration, zufällige Workarounds)
• Liefert klare, handlungsfähige Fehler (keine stillen Fehler)

Scannen Sie anschließend nach roten Flaggen, die Sie ohne Security-Expertise entdecken können: in das Repo committete Secrets, temporäre Auth-Bypässe, rohe SQL-Abfragen aus Benutzereingaben oder API-Routen ohne Zugriffskontrollen. Wenn ein Repo offensichtlich gebrochene Auth oder klare Injection-Risiken hat, gehen Sie davon aus, dass das ein tieferes Problem ist, als es scheint.

Schauen Sie dann auf Struktur und Build-Hygiene. Ein gesünderes Repo hat meist ein offensichtliches Layout (UI, Backend, Migrationen), Umgebungsvariablen an einem Ort und einen klaren Weg zum Ausführen und Bereitstellen. Wenn Logik über zufällige Dateien dupliziert ist, die Benennung inkonsistent ist oder es mehrere konkurrierende Konfigurationsdateien gibt, zahlen Sie später dafür.

Führen Sie schließlich den Wartbarkeitstest durch: Kann eine neue Person innerhalb von 30 Minuten finden, wo die Anmeldung passiert, wo Daten gespeichert werden und wo die Haupt-API-Routen leben? Wenn nicht, kommen Bugs nach „Fixes“ immer wieder zurück.

Schritt-für-Schritt: Gewinner-Repo wählen und das andere einfrieren

Zwei Repos parallel zu halten verdoppelt Ihre Bugs und Entscheidungen. Der schnellste Weg ist, ein Repo als Quelle der Wahrheit zu wählen und das andere nur noch als Feature-Spender zu behandeln.

Wählen Sie die Basis, die am sichersten und am einfachsten auszuliefern ist, auch wenn die UI weniger poliert wirkt. Sicherheit bedeutet weniger Unbekannte, weniger Abkürzungen und weniger Stellen, an denen eine Änderung drei Screens bricht.

Wenn Sie nicht weiterkommen, bewerten Sie beide Repos anhand einiger realistischer Checks:

• Kann ein neuer Mitarbeiter es lokal ohne Detektivarbeit ausführen?
• Funktioniert Auth End-to-End (Registrierung, Login, Reset, Logout)?
• Werden Secrets sicher gehandhabt (nicht hardcodiert oder exponiert)?
• Ist das Datenmodell konsistent (ein klares Schema, minimale Hacks)?
• Kann man es deployen ohne One-off manuelle Fixes?

Sobald Sie den Gewinner gewählt haben, frieren Sie das andere Repo ein. Keine neuen Features, keine „Quick Fixes“, kein paralleles Neuaufbauen. Machen Sie es schreibgeschützt, damit es nicht still weiterdriftet und das Team zurück in Split-Brain-Entwicklung zieht.

Schreiben Sie als Nächstes eine kurze „Must-Keep“-Liste aus dem Verlierer-Repo. Beschreiben Sie Ergebnisse, nicht Screens: „Nutzer können Rechnungen exportieren“, „Admins können Rückerstattungen durchführen“, „Kunden können Zahlungsmethode aktualisieren“. Das wird Ihr Migrations-Backlog.

Dokumentieren Sie abschließend Ihre Nichtverhandelbaren an einem Ort: Nutzer, Zahlungen, Berechtigungen und die Kernflüsse, die das Geschäft am Leben halten. Beispiele:

• Bestehende Nutzer müssen sich mit derselben E-Mail einloggen können.
• Keine Doppelbuchungen.
• Nur Admins dürfen Kundendaten einsehen.

Schritt-für-Schritt: Features migrieren ohne die Bugs zu übernehmen

Die sicherste Methode ist langweilig: Bewegen Sie jeweils einen funktionierenden Nutzer-Flow und beweisen Sie, dass er funktioniert, bevor Sie den nächsten angehen.

Beginnen Sie mit dem kleinsten vertikalen Slice, den Sie Ende-zu-Ende ausliefern können. Wählen Sie einen Flow, der UI, Backend und Daten berührt, aber überschaubar bleibt (zum Beispiel: Registrierung, einen Eintrag erstellen, ihn in einer Liste sehen). Das zeigt schnell Routing-, API- und Datenbankannahmen, ohne Sie in endlose Edge-Cases zu ziehen.

Portieren Sie Verhalten, nicht Code

Behandeln Sie das alte Repo als Spezifikation, nicht als Quelldatei zum Kopieren. Lesen Sie, was es tut, und implementieren Sie dieses Verhalten sauber im neuen Repo. Dateien zu kopieren importiert oft versteckte Globals, unsichere Queries und „funktioniert-auf-meinem-Rechner“-Hacks.

Ein praktischer Loop:

• Schreiben Sie die erwarteten Eingaben, Ausgaben und Fehlermeldungen für den Flow auf.
• Bauen Sie Endpunkte und UI basierend auf diesem Verhalten neu.
• Halten Sie Datenmodelländerungen minimal, bis der Flow stabil ist.
• Fügen Sie ein kleines Feature-Flag hinzu (auch eine Konfig-Option), damit Sie den neuen Flow an- und ausschalten können.

Wenn der Slice funktioniert, bewegen Sie das nächste Feature auf dieselbe Weise. Halten Sie Migrationen klein und Merge-Requests fokussiert. Zwei unabhängige Features gleichzeitig zu migrieren macht es schwer festzustellen, was kaputt ging.

Verifizieren nach jedem Schritt

Nach jedem Feature führen Sie dieselben Kurzchecks aus:

• Durchlaufen Sie den Flow zweimal (neuer Nutzer und bestehender Nutzer).
• Prüfen Sie, ob die in die Datenbank geschriebenen Daten den Erwartungen entsprechen.
• Bestätigen Sie, dass keine neuen Fehler oder Warnungen in den Server-Logs erschienen sind.
• Bestätigen Sie, dass Sie zurückrollen können (Flag wieder umschalten).

Wenn ein Repo Einladungen für Teammitglieder hat, kopieren Sie den Invite-Code nicht wortwörtlich. Rekreieren Sie das Invite-Verhalten (wer darf einladen, was wird gesendet, wie funktioniert die Annahme), und prüfen Sie dann, dass keine Tokens in Logs geleakt werden.

Hochrisikobereiche: Auth und Datenmigrationen

Beim Zusammenführen zweier Codebasen sind Authentifizierung und Daten am wahrscheinlichsten dafür, in Produktion zu brechen. In Demos sehen sie oft „fertig" aus, aber kleine Unterschiede zwischen Repos können Nutzer aussperren, Daten leaken oder Datensätze beschädigen.

Authentifizierung: End-to-End beweisen

Prüfen Sie Auth, bevor Sie „nice-to-have“-Features bewegen. Überprüfen Sie nicht nur, ob eine Login-Seite existiert. Prüfen Sie die komplette Schleife: Anmeldung, Session-Speicherung, Logout und das Verhalten bei Fehlern.

Ihre grundlegenden Auth-Checks sollten abdecken:

• Login funktioniert mit echten Accounts, nicht nur Demo-Usern.
• Sessions bleiben nach einem Reload erhalten und laufen wie erwartet ab.
• Passwort-Reset-Tokens funktionieren und können nicht wiederverwendet werden.
• OAuth-Callbacks stimmen mit den richtigen Domains und Redirect-Pfaden überein.
• Rollen und Berechtigungen entsprechen dem beabsichtigten Verhalten (Admin vs Member vs Guest).

Ein gängiger Fehler bei Migrationen: Repo A verwendet Cookie-Sessions, Repo B verwendet Tokens im Local Storage. Beide können alleine „funktionieren“, aber gemischt führen sie zu zufälligen Logouts und kaputten Schutzmechanismen.

Datenmigrationen: Modell kartieren, dann sicher verschieben

Bevor Sie Features migrieren, schreiben Sie das Datenmodell in einfachem Deutsch auf: Tabellen oder Collections, erforderliche Felder, Beziehungen und was null sein darf. Wenn dasselbe Konzept unterschiedlich benannt ist (userId vs owner_id), behandeln Sie das als Migrationsproblem, nicht als Suche-und-Ersetzen-Aufgabe.

Planen Sie Migrationen wie ein kontrolliertes Release:

• Machen Sie ein Backup, das Sie schnell wiederherstellen können.
• Proben Sie auf Staging mit realistischer Datenmenge.
• Definieren Sie Rollback (und was es bedeutet, wenn Daten teilweise bereits verschoben wurden).
• Migrieren Sie in kleinen Chargen, wenn möglich.
• Validieren Sie Summen und prüfen Sie stichprobenartig kritische Datensätze (Nutzer, Zahlungen, Berechtigungen).

Verifikation bei engem Zeitbudget: Tests, die Sie wirklich brauchen

Geschwindigkeit zählt, aber das Auslassen grundlegender Prüfungen ist der Weg, denselben Bug zweimal auszuliefern. Das Ziel ist keine perfekte Abdeckung, sondern Vertrauen, dass die neue Quelle der Wahrheit für echte Nutzer funktioniert.

Sperren Sie zuerst eine minimale Menge an End-to-End-Checks. Das sind die Flows, die beweisen, dass die App nutzbar und „Geld-sicher" ist:

• Registrierung und Onboarding (wie es bei Ihnen wirklich ist)
• Login, Logout und Passwort-Reset
• Der Kernworkflow, für den Nutzer wirklich zahlen
• Zahlungen und Rückerstattungen (falls vorhanden), inklusive eines fehlgeschlagenen Zahlungsversuchs
• Eine Admin- oder Einstellungsaktion, die Daten ändert

Fügen Sie dann ein paar günstige automatisierte Checks hinzu, die frühe Brüche auffangen:

• Linting und Formatierung
• Typprüfungen (wenn Sie TypeScript verwenden)
• Eine kleine Anzahl von Unit-Tests für stabile Logik

Halten Sie Staging nah an der Produktion. Verwenden Sie dieselben Namen für Umgebungsvariablen und dieselbe Lademethode, und stimmen Sie den Datenbanktyp ab. Ein klassischer Fehler ist „funktioniert auf Staging", weil Staging SQLite nutzt, während Produktion Postgres verwendet.

Führen Sie ein kurzes Bug-Tagebuch: was kaputt ging, wo es gefixt wurde und was es früher entdeckt hätte (ein Test, eine Linter-Regel, eine fehlende Env-Var). Das verhindert, dass derselbe Bug bei späteren Migrationen zurückkehrt.

Übliche Fallen, die das gleiche Chaos wieder erzeugen

Die meisten Teams geraten in Schwierigkeiten, wenn sie das Zusammenführen als simples „Best of both" ansehen. Wenn beide Repos schnell von unterschiedlichen AI-Tools erzeugt wurden, teilen sie oft dieselben Schwachstellen, nur an anderen Stellen.

Diese Fallen führen typischerweise zum gleichen Durcheinander:

• Einen riesigen Merge machen und dann Wochen damit verbringen, Konflikte und duplizierte Logik zu entwirren.
• Ganze Dateien per Copy-Paste verschieben und unsichere Muster importieren (fest codierte Secrets, unsichere SQL, fehlende Auth-Prüfungen).
• UI und Backend gleichzeitig ändern, sodass man nicht erkennen kann, welche Änderung den Fehler verursacht hat.
• Dependencies auseinanderdriften lassen, sodass Builds auf einer sauberen Maschine oder in CI fehlschlagen.
• Deployment als letzten Schritt behandeln und spät feststellen, dass Env-Vars, Migrationen oder Hosting-Annahmen nicht übereinstimmen.

Ein kleines Beispiel: Sie kopieren eine „funktionierende" Login-Seite aus Repo B nach Repo A. Sie sieht gut aus, bringt aber einen Helfer mit, der Tokens in die Konsole logged und serverseitige Session-Checks überspringt. Sie haben den Screen repariert, aber die Sicherheitslücke wieder eingeführt.

Schutzmechanismen, die Sie voranbringen:

• Bewegen Sie einen Feature-Slice nach dem anderen und setzen Sie vor dem nächsten einen Checkpoint.
• Implementieren Sie minimales Verhalten neu im Gewinner-Repo, statt Dateien zu kopieren.
• Pinnen Sie Laufzeit- und Paketversionen früh und verifizieren Sie saubere Installationen.
• Machen Sie so früh wie möglich einen „deploy early" Dry-Run, sobald das erste migrierte Feature landet.

Schnelle Checkliste, bevor Sie sich für den Wechsel entscheiden

Bevor Sie zwei Codebasen in einen Pfad zusammenführen, halten Sie kurz inne und stellen Sie sicher, dass Sie mit der Entscheidung für die nächsten Wochen leben können. Das Ziel ist vorhersehbares Ausliefern und weniger Überraschungen.

Zuerst: Machen Sie das Verlierer-Repo sicher aufbewahrbar, ohne dass es weiter verändert wird. Wenn Leute dort noch Quick-Fixes pushen können, landen Sie wieder in zwei Realitäten.

Verwenden Sie das folgende als Gate:

• Das alte Repo ist eingefroren (read-only), klar als archiviert markiert und Sie haben den zuletzt bekannten guten Commit oder Tag dokumentiert.
• Das gewählte Repo baut von Grund auf auf einer sauberen Maschine mit schriftlich festgehaltenen Schritten (Install, Env-Vars, Build, Run) und diese Schritte funktionieren zweimal hintereinander.
• Deployment ist reproduzierbar und Sie können auf den vorherigen Build zurückrollen.
• Anmeldung und Registrierung funktionieren End-to-End für neue und bestehende Nutzer, inklusive Passwort-Reset und Session-Expiry.
• Keine Secrets sind committet, und Umgebungsvariablen sind dokumentiert.

Eine konkrete Validierungsmethode für den letzten Punkt: Führen Sie die drei wichtigsten Nutzerreisen auf Staging aus (z. B. Registrieren, Hauptaufgabe abschließen, bezahlen oder exportieren) mit Testkonten und produktionsähnlichem Datenvolumen.

Beispiel: Entscheidung zwischen einem v0-Build und einem Replit-Neubau

Ein Gründer hat zwei Versionen derselben App. Die erste ist ein v0-Build, der hübsch aussieht und die meisten Screens hat, aber hauptsächlich Frontend ist. Die zweite ist ein Replit Full-Stack-Neubau, der sich einloggen und Daten speichern kann, aber die UI ist roh und Teile der Logik sind dupliziert.

Das Ziel ist nicht zeilenweises Zusammenführen. Es geht darum, ein Repo als Quelle der Wahrheit zu wählen und nur die Teile zu übernehmen, die sich bewähren.

Sie vergleichen beide Repos anhand einiger Checks:

• Welches hat funktionierende Auth End-to-End (Registrierung, Login, Logout, Session-Expiry)?
• Welches hat ein klareres Datenmodell (klarere Namen, weniger One-off-Felder)?
• Welches lässt sich ohne manuelle Schritte oder überall verstreute Secrets deployen?
• Welches hat weniger „magische" Fixes (fest codierte IDs, versteckte Admin-Routen, zufällige Timeouts)?

In diesem Fall gewinnt das Replit-Repo, weil Auth funktioniert und das Datenmodell näher am Geschäftsbedarf ist. Das v0-Repo wird nur als Design-Referenz behalten.

Die Migration erfolgt Feature für Feature. Anstatt die komplette v0-UI zu kopieren, baut das Team die Schlüssel-Screens als Komponenten im Replit-Repo neu und verbindet sie mit dem vorhandenen Backend. Sie beginnen mit den wertvollsten Flows: Onboarding, Haupt-Dashboard und der täglichen Kernaktion der Nutzer.

Bevor sie fertig sind, validieren sie Verhalten, nicht nur Optik. Rollen und Berechtigungen müssen übereinstimmen, Formulare benötigen dieselben Pflichtfelder und Fehlerzustände müssen klar sein (falsches Passwort, fehlendes Feld, fehlgeschlagenes Speichern).

Nächste Schritte: zu einer auslieferungsfähigen Codebasis kommen

Wenn Sie zwei Codebasen zusammenführen müssen, ist der schnellste Weg, das Chaos zu beenden, die Feature-Arbeit zu pausieren und ein kurzes schriftliches Audit zu machen. Sie urteilen nicht über Stil, sondern identifizieren, was sicher auslieferbar ist und was später bricht.

Schreiben Sie auf, was Sie heute wissen:

• Die ärgerlichsten, nutzerrelevanten Bugs (was, wo, wie reproduzieren)
• Die größten Risiken (Sicherheit, Datenverlust, unerwartete Kosten)
• Die Features, die Sie behalten müssen (und was warten kann)
• Was bereits in Produktion funktioniert (auch wenn es hässlich ist)
• Was Deploys blockiert (Env-Vars, Build-Schritte, fehlende Migrationen)

Treffen Sie dann eine Entscheidung: reparieren und migrieren, oder von Grund auf neu bauen anhand derselben Anforderungen. Wenn ein Repo ein stabiles Datenmodell und vorhersehbare Deploys hat, gewinnt es oft, selbst wenn die UI hinterherhinkt. Wenn beide Repos wackelig sind, kann ein sauberer Neubau günstiger sein als zwei Problem-Sets weiterzuziehen.

Holen Sie Hilfe, sobald Sie rote Flaggen sehen wie exponierte Secrets, gebrochene Auth, unklare Datenbank-Verantwortung oder Deploys, die nur auf einer Maschine funktionieren.

Wenn Sie AI-erzeugte Prototypen geerbt haben und eine produktionsreife Codebasis wollen, ist FixMyMess (fixmymess.ai) genau für diese Situation gebaut. Sie können beide Repos diagnostizieren, gebrochene Logik reparieren, Sicherheit härten, chaotische Architektur refactoren und die App für die Bereitstellung vorbereiten. Falls Sie unsicher sind, welches Repo gewinnen sollte, kann ein kostenloser Code-Audit Ihnen einen klaren, stressfreien Plan geben, bevor Sie sich festlegen.