Fusionar dos bases de código: elegir una única fuente de verdad y migrar de forma limpia

Por qué dos bases de código creadas por IA se vuelven un problema rápido

Dos herramientas de IA pueden producir dos versiones muy distintas de la misma app en un fin de semana. Quizá empezaste con un v0 por rapidez y luego rehíces en Replit cuando las cosas se complicaron. O un compañero probó Lovable o Bolt y “arregló” algunas pantallas allí. Cada repo puede verse creíble por sí mismo, así que da tentación mantener ambos y solucionarlo después.

Ahí es donde empiezan los problemas. Los prototipos divergen con rapidez. La UI puede parecer similar, pero la lógica debajo casi nunca lo es. Un repo almacena roles en una tabla, el otro los guarda en un blob JSON. Uno asume login por email, el otro asume OAuth. Una semana después no tienes solo dos bases de código. Tienes dos conjuntos de supuestos.

Los modos de fallo comunes aparecen pronto:

• El mismo bug existe dos veces, pero con síntomas distintos.
• Las reglas de negocio chocan (precios, permisos, estados), así que lo “correcto” depende de qué repo ejecutes.
• Los modelos de datos se desalinean, haciendo las migraciones riesgosas y los informes poco fiables.
• Correcciones de seguridad llegan solo a un sitio, dejando al otro como una trampa.

Intentar fusionar dos bases de código línea a línea suele empeorar las cosas. Acabas cosiendo patrones incompatibles, copiando flujos de autenticación rotos y trayendo consultas inseguras o secretos filtrados desde el repo más débil. El resultado es una tercera base de código más difícil de entender que cualquiera de las originales.

Un buen resultado es simple: una única base de código fuente de verdad, una sola vía de despliegue y un solo lugar para corregir bugs. Aún puedes reutilizar buenas ideas del otro repo, pero solo migrando funciones de forma intencional. El objetivo no es “combinarlo todo”. Es “elegir uno en el que confiar y mover solo lo que puedas verificar”.

Qué significa “fuente de verdad” (y qué no)

Una base de código fuente de verdad es el único lugar donde se permiten llegar cambios nuevos. Si una funcionalidad se publica, se publica desde ahí. Si se corrige un bug, la corrección va allí. Todo lo demás se convierte en material de referencia, no en un segundo producto activo.

No significa que el repo elegido sea perfecto, limpio o incluso el que más te guste. Tampoco significa borrar el otro repositorio el primer día. Puedes conservarlo para comparaciones o para entender qué esperan los usuarios. La diferencia es la gobernanza: solo un repo avanza.

Antes de elegir, define qué cubre la “verdad” para no pelear después. Dilo claro:

• Comportamiento del producto (funciones y flujos clave de UX)
• Modelo de datos y migraciones
• Autenticación y permisos
• Configuración de despliegue y entorno
• Logging y manejo de errores

Luego establece una regla que todos sigan: el repositorio ganador es la única vía escribible. El otro pasa a solo lectura y se queda así.

También fija una fecha límite para decidir. Los prototipos generados por IA divergen rápido, especialmente si dos herramientas siguen generando archivos nuevos. Un objetivo práctico es 24 a 72 horas: elige uno, congela el otro y migra con intención. Si dudas sobre cuál es más seguro, una auditoría rápida puede sacar a la luz problemas de alto riesgo temprano, especialmente alrededor de auth, secretos y escrituras en la base de datos.

Una forma rápida de comparar dos bases de código sin ser experto

Cuando necesitas fusionar dos bases, no empieces por debatir cuál “se ve mejor”. Empieza comprobando cuál se comporta como software real bajo presión básica: ejecutar, compilar, desplegar y fallar de formas previsibles.

Un sencillo cuadro de puntuación fuerza una comparación justa. Da a cada repo un 0-2 (0 = falla, 1 = inestable, 2 = sólido) para:

• Se ejecuta localmente desde una instalación limpia (sin pasos manuales secretos)
• Se compila y despliega de forma repetible
• Tiene al menos algunas pruebas significativas (o puedes añadirlas rápido)
• Evita hacks (URLs hardcodeadas, config copiada, workarounds aleatorios)
• Genera errores claros sobre los que se pueda actuar (no fallos silenciosos)

Después, busca señales de alerta que puedas detectar sin ser especialista en seguridad: secretos comprometidos en el repo, bypasses de autenticación “temporales”, SQL crudo construido desde entradas de usuario o rutas de API sin comprobaciones de acceso. Si un repo tiene auth claramente rota o riesgos de inyección, asume que el problema es más profundo de lo que parece.

Luego mira la estructura y la higiene de build. Un repo más sano suele tener un layout obvio (UI, backend, migraciones), variables de entorno en un solo lugar y una forma clara de ejecutar y desplegar. Si la lógica está duplicada en archivos al azar, los nombres son inconsistentes o hay múltiples archivos de configuración en competencia, lo pagarás después.

Finalmente, haz una prueba de mantenibilidad simple: ¿puede una persona nueva encontrar dónde ocurre el login, dónde se guarda la información y dónde están las rutas API principales en 30 minutos? Si no, los bugs seguirán volviendo después de “arreglos”.

Paso a paso: elegir el repo ganador y congelar el otro

Mantener dos repos aumenta los bugs y las decisiones. La vía más rápida es elegir un repo como fuente de verdad y tratar el otro solo como donante de funciones.

Elige la base que sea más segura y fácil de publicar, aunque la UI se vea menos pulida. Seguridad significa menos incógnitas, menos atajos y menos puntos donde un cambio rompe tres pantallas.

Si estás atascado, evalúa ambos repos con algunas comprobaciones reales:

• ¿Puede alguien nuevo ejecutarlo localmente sin trabajo de detective?
• ¿Funciona la autenticación end-to-end (signup, login, reset, logout)?
• ¿Los secretos se manejan de forma segura (no hardcodeados ni expuestos)?
• ¿El modelo de datos es consistente (un esquema claro, hacks mínimos)?
• ¿Puedes desplegarlo sin correcciones manuales puntuales?

Una vez elegido el ganador, congela el otro repo. Nada de nuevas funciones, ni “arreglos rápidos”, ni reconstrucciones en paralelo. Manténlo en solo lectura para que no pueda desviarse y arrastrar al equipo de vuelta a un desarrollo dividido.

Después, escribe una breve lista de lo que debe conservarse del repo perdedor. Describe resultados, no pantallas: “los usuarios pueden exportar facturas”, “los admins pueden reembolsar”, “los clientes pueden actualizar el método de pago”. Eso será tu backlog de migración.

Por último, documenta tus no negociables en un solo lugar: usuarios, pagos, permisos y los flujos centrales que mantienen vivo el negocio. Ejemplos:

• Los usuarios existentes deben poder iniciar sesión con el mismo email.
• No cobrar doble.
• Solo los administradores pueden ver datos de clientes.

Paso a paso: migrar funcionalidades sin copiar errores

El enfoque más seguro es aburrido: mover un flujo de usuario que funcione a la vez y demostrar que funciona antes de tocar el siguiente.

Empieza con la rebanada vertical más pequeña que puedas publicar de extremo a extremo. Elige un flujo que toque UI, backend y datos, pero que esté contenido (por ejemplo: registro, crear un ítem y verlo en una lista). Esto revela rápido suposiciones de routing, forma de las API y la base de datos sin arrastrarte a casos límite sin fin.

Porta comportamiento, no código

Trata el repo antiguo como una especificación, no como un archivo para copiar. Lee lo que hace y vuelve a implementar ese comportamiento de forma limpia en el repo nuevo. Copiar archivos es como importar variables globales ocultas, consultas inseguras y hacks de “funciona en mi máquina”.

Un bucle práctico:

• Anota las entradas esperadas, las salidas y los mensajes de fallo para el flujo.
• Reconstruye los endpoints y la UI basándote en ese comportamiento.
• Mantén los cambios en el modelo de datos al mínimo hasta que el flujo sea estable.
• Añade una bandera de característica pequeña (incluso un toggle de config) para poder activar o desactivar el flujo nuevo.

Cuando la rebanada funcione, mueve la siguiente característica de la misma manera. Mantén las migraciones pequeñas y los pull requests enfocados. Migrar dos funciones no relacionadas al mismo tiempo dificulta saber qué causó la rotura.

Verifica después de cada movimiento

Después de cada función, realiza las mismas comprobaciones rápidas:

• Completa el flujo dos veces (usuario nuevo y usuario existente).
• Verifica que los datos escritos en la base coinciden con lo esperado.
• Confirma que no aparecieron nuevos errores o advertencias en los logs del servidor.
• Confirma que puedes revertir (volver a apagar el toggle).

Si un repo tiene invitaciones de equipo, no copies el código de invitación tal cual. Recrea el comportamiento de invitación (quién puede invitar, qué se envía, cómo se acepta) y verifica que no filtra tokens en logs.

Áreas de alto riesgo: auth y migraciones de datos

Al fusionar dos repos, las partes más propensas a fallar en producción son autenticación y datos. A menudo parecen “listas” en una demo, pero pequeñas diferencias entre repos pueden bloquear usuarios, filtrar datos o corromper registros.

Autenticación: pruébala de extremo a extremo

Audita auth antes de mover funciones que no son críticas. No te limites a comprobar que existe una página de login. Revisa el bucle completo: sign-in, almacenamiento de sesión, logout y cómo se comportan los errores.

Tus comprobaciones básicas de auth deben cubrir:

• El login funciona con cuentas reales, no solo usuarios de demo.
• Las sesiones persisten tras un refresh y expiran cuando deben.
• Los tokens de reset de contraseña funcionan y no se pueden reutilizar.
• Los callbacks de OAuth coinciden con los dominios y rutas de redirección correctas.
• Roles y permisos coinciden con lo que realmente quieres (admin vs miembro vs invitado).

Un fallo común en migraciones: el Repo A usa sesiones por cookie y el Repo B usa tokens en localStorage. Ambos pueden “funcionar” por separado, pero mezclarlos crea cierres de sesión aleatorios y protecciones rotas.

Migraciones de datos: mapea el modelo y muévelo con seguridad

Antes de migrar funciones, escribe el modelo de datos en lenguaje sencillo: tablas o colecciones, campos requeridos, relaciones y qué puede ser nulo. Si el mismo concepto tiene nombres distintos (userId vs owner_id), trátalo como un problema de migración, no como un find-and-replace.

Planifica migraciones como un despliegue controlado:

• Haz una copia de seguridad que puedas restaurar rápido.
• Ensaya en staging con volumen de datos realista.
• Define el rollback (y qué pasa si parte de los datos ya se movió).
• Migra en pequeños lotes cuando sea posible.
• Valida totales y revisa registros críticos (usuarios, pagos, permisos).

Verificación con tiempo limitado: pruebas que realmente necesitas

La velocidad importa, pero saltarse comprobaciones básicas es cómo publicas el mismo bug dos veces. El objetivo no es cobertura perfecta, es tener confianza de que la nueva fuente de verdad funciona para usuarios reales.

Empieza bloqueando un conjunto mínimo de checks end-to-end. Son los flujos que demuestran que la app es usable y segura para el dinero:

• Registro y onboarding reales
• Login, logout y reset de contraseña
• El flujo principal por el que los usuarios pagan
• Pagos y reembolsos (si existen), incluyendo un pago fallido
• Una acción de admin o de configuración que cambie datos

Luego añade algunas comprobaciones automáticas baratas que capturen fallos temprano:

• Lint y formato
• Chequeos de tipos (si usas TypeScript)
• Un pequeño número de tests unitarios donde la lógica es estable

Mantén staging cerca de producción. Usa los mismos nombres de variables de entorno y el mismo método de carga, y empareja el tipo de base de datos. Un fallo clásico es “funciona en staging” porque staging usa SQLite y producción usa Postgres.

Mientras verificas, lleva un breve diario de bugs: qué falló, dónde se arregló y qué lo habría detectado antes (una prueba, una regla de linter, una variable de entorno faltante). Esto evita que el mismo bug vuelva en migraciones posteriores.

Trampas comunes que recrean el mismo desastre

La mayoría de equipos se mete en problemas cuando tratan la fusión como un simple ejercicio de “lo mejor de ambos”. Si ambos repos fueron producidos rápido por distintas herramientas de IA, suelen compartir los mismos puntos débiles, solo en sitios diferentes.

Estas trampas tienden a recrear el desastre:

• Hacer una mega fusión y luego pasar semanas desenredando conflictos y lógica duplicada.
• Copiar y pegar archivos enteros para mover funciones e importar patrones inseguros (secretos hardcodeados, SQL inseguro, checks de auth faltantes).
• Cambiar UI y backend al mismo tiempo, de modo que no puedas saber qué cambio provocó la rotura.
• Dejar que las dependencias se desvíen y luego fallan las builds en una máquina limpia o en CI.
• Tratar el despliegue como un paso final y descubrir tarde que las env vars, migraciones o supuestos de hosting no coinciden.

Un ejemplo pequeño: copias una página de login “funcionando” del Repo B al Repo A. Se ve bien, pero trae también un helper que loguea tokens en consola y omite comprobaciones de sesión en el servidor. Arreglaste la pantalla, pero reintrodujiste el agujero de seguridad.

Guardarraíles para mantener el avance:

• Mover una rebanada de función a la vez y añadir un punto de control antes de la siguiente.
• Re-implementar el comportamiento mínimo en el repo ganador en vez de copiar archivos.
• Fijar versiones de runtime y paquetes temprano y verificar instalaciones limpias.
• Hacer un ensayo de despliegue tan pronto como la primera función migrada aterrice.

Lista rápida antes de comprometerte con el cambio

Antes de unir dos bases de código en una sola vía, pausa y asegúrate de poder vivir con la decisión por las próximas semanas. La meta es publicar con previsibilidad y tener menos sorpresas.

Primero, deja el repo perdedor seguro para mantenerlo sin permitir cambios. Si la gente aún puede hacer arreglos rápidos allí, volverás a tener dos realidades.

Usa esto como puerta de entrada:

• El repo antiguo está congelado (solo lectura), marcado claramente como archivado y registraste el último commit o tag conocido bueno.
• El repo elegido se compila desde cero en una máquina limpia con pasos escritos (instalar, vars de entorno, compilar, ejecutar), y esos pasos funcionan dos veces seguidas.
• El despliegue es repetible y puedes retroceder a la build anterior.
• Login y signup funcionan de extremo a extremo para usuarios nuevos y existentes, incluyendo reset de contraseña y expiración de sesiones.
• No hay secretos comprometidos y las variables de entorno están documentadas.

Una forma concreta de validar lo último: ejecuta los tres recorridos de usuario principales en staging (por ejemplo: registro, completar la tarea principal, pagar o exportar), usando cuentas de prueba y volumen de datos parecido a producción.

Ejemplo: elegir entre un v0 y una reconstrucción en Replit

Un fundador acaba con dos versiones de la misma app. La primera es un v0 que se ve bien y tiene la mayoría de pantallas, pero es mayormente frontend. La segunda es una reconstrucción full-stack en Replit que puede iniciar sesión y guardar datos, pero la UI es tosca y parte de la lógica está duplicada.

La meta no es fusionar línea por línea. Es elegir un repo como fuente de verdad y mover solo las partes que merecen quedarse.

Comparan ambos repos con algunas comprobaciones:

• ¿Cuál tiene autenticación end-to-end (signup, login, logout, expiración de sesión)?
• ¿Cuál tiene un modelo de datos más limpio (nombres claros, menos campos puntuales)?
• ¿Cuál despliega sin pasos manuales o claves secretas esparcidas en el repo?
• ¿Cuál tiene menos “arreglos mágicos” (IDs hardcodeados, rutas admin ocultas, timeouts aleatorios)?

En este caso, gana el repo de Replit porque la auth funciona y el modelo de datos se acerca más a lo que el negocio necesita. El repo v0 pasa a ser solo referencia de diseño.

La migración ocurre función por función. En vez de copiar toda la UI del v0, el equipo reconstruye las pantallas clave como componentes dentro del repo de Replit, conectadas al backend existente. Empiezan por los flujos de mayor valor: onboarding, el panel principal y la acción que los usuarios hacen cada día.

Antes de darlo por terminado, validan comportamiento, no solo visuales. Roles y permisos deben coincidir, los formularios necesitan los mismos campos requeridos y los estados de error deben ser claros (contraseña incorrecta, campo faltante, guardado fallido).

Próximos pasos: llegar a una sola base de código publicable

Si necesitas fusionar dos bases de código, la forma más rápida de parar el caos es pausar el trabajo de funciones y hacer una auditoría escrita corta. No estás juzgando estilo de código. Estás identificando qué es seguro publicar y qué va a romper más adelante.

Anota lo que sabes hoy:

• Los bugs más dolorosos para usuarios (qué, dónde, cómo reproducir)
• Los mayores riesgos (seguridad, pérdida de datos, costes sorpresa)
• Las funciones que debes conservar (y qué puede esperar)
• Lo que ya funciona en producción (aunque sea feo)
• Lo que bloquea el despliegue (env vars, pasos de build, migraciones faltantes)

Luego toma una decisión: reparar y migrar, o reconstruir desde cero con los mismos requerimientos. Si un repo tiene un modelo de datos estable y despliegues previsibles, suele ganar aunque la UI esté rezagada. Si ambos repos son inestables, una reconstrucción limpia puede salir más barata que arrastrar dos conjuntos de problemas.

Trae ayuda tan pronto veas señales rojas como secretos expuestos, auth rota, propiedad de base de datos poco clara o despliegues que solo funcionan en una máquina.

Si heredaste prototipos generados por IA y quieres una base de código lista para producción, FixMyMess (fixmymess.ai) está pensado para esta situación exacta. Pueden diagnosticar ambos repos, reparar lógica rota, endurecer la seguridad, refactorizar arquitectura desordenada y preparar la app para el despliegue. Si no sabes cuál repositorio debería ganar, empezar con su auditoría gratuita puede darte un plan claro y sin drama antes de comprometerte.