Cómo resolver conflictos en Git paso a paso (sin romper tu proyecto)
Hay un momento bastante típico cuando empiezas a trabajar con Git en serio: todo va bien hasta que aparece un error raro al hacer git push… 😅
Y entonces ves algo como esto:
1
! [rejected] main -> main (fetch first)
Ahí es donde empiezan los conflictos.
🧠 Qué está pasando realmente
Un conflicto en Git ocurre cuando:
- Has hecho cambios en un archivo
- Otra versión de ese mismo archivo ya existe en remoto
- Y ambos cambios afectan a la misma zona
Un caso muy real:
- En el trabajo modificas
page.tsx - En casa modificas también
page.tsx - Subes uno de los cambios
- Intentas subir el otro…
💥 Git no sabe cuál elegir
📉 El error típico al hacer push
1
git push
Resultado:
1
! [rejected] main -> main (fetch first)
Esto significa:
👉 “Antes de subir tus cambios, necesitas traer los últimos del repositorio”
🔄 El primer paso siempre: sincronizar
1
git pull
Aquí pueden pasar dos cosas:
🟢 Caso 1: todo se mezcla automáticamente
Git hace magia:
1
Auto-merging page.tsx
Y puedes seguir sin problemas:
1
git push
🔴 Caso 2: conflicto detectado
Aquí es donde entra lo interesante:
1
CONFLICT (content): Merge conflict in page.tsx
Git no ha podido resolverlo solo.
🧩 Cómo se ve un conflicto dentro del código
Cuando abres el archivo, verás algo así:
1
2
3
4
5
<<<<<<< HEAD
const mensaje = "Hola desde el trabajo";
=======
const mensaje = "Hola desde casa";
>>>>>>> main
Estas marcas indican:
HEAD→ tu versión actual=======→ separaciónmain→ versión remota
✍️ Resolver el conflicto paso a paso
Aquí no hay automatismo: decides tú.
Por ejemplo, puedes dejar:
1
const mensaje = "Hola desde casa y trabajo";
Y eliminar completamente:
1
2
3
<<<<<<< HEAD
=======
>>>>>>>
✅ Guardar la solución
Una vez editado:
1
2
3
git add .
git commit -m "resuelvo conflicto"
git push
Y listo 🚀
⚡ Forma más profesional: usar rebase
En lugar de git pull, puedes usar:
1
git pull --rebase
Esto hace que:
- Tus cambios se apliquen después de los remotos
- El historial sea más limpio
- Haya menos merges innecesarios
🧠 Cómo evitar conflictos (o al menos reducirlos)
Algunas reglas que acaban saliendo solas con el tiempo:
- Antes de trabajar:
1
git pull
- Haz commits pequeños y frecuentes
- Evita editar el mismo archivo en dos sitios a la vez
- Divide componentes (por ejemplo en Next.js)
Ejemplo:
En vez de un solo archivo gigante:
1
page.tsx
Divide en:
1
2
3
components/Header.tsx
components/Footer.tsx
components/Card.tsx
👉 Menos probabilidad de pisarte a ti mismo
🧩 Un caso práctico rápido
Imagina este flujo:
- En casa:
1
2
git commit -m "añado header"
git push
- En el trabajo (sin hacer pull):
1
2
git commit -m "cambio estilos"
git push ❌
- Solución:
1
2
3
git pull
# resolver conflicto
git push
📌 Idea clave que conviene interiorizar
Git no se equivoca ni “rompe cosas”.
Simplemente te dice:
👉 “Aquí hay dos versiones distintas, decide tú cuál es la correcta”
Y eso, aunque al principio asuste un poco, es justo lo que evita perder código sin darte cuenta.
❓ FAQ
¿Qué es un conflicto en Git?
Un conflicto en Git ocurre cuando dos cambios afectan a la misma parte de un archivo y Git no puede decidir automáticamente cuál mantener, por lo que requiere intervención manual.
¿Cuándo suelen aparecer los conflictos en Git?
Suelen aparecer cuando trabajas en varios ordenadores o ramas y modificas el mismo archivo sin haber sincronizado antes con git pull.
¿Cómo se resuelve un conflicto en Git?
Se resuelve editando manualmente el archivo afectado, eliminando las marcas de conflicto y dejando el código final deseado, para luego hacer git add, git commit y git push.
¿Se pueden evitar los conflictos en Git?
Sí, se pueden reducir haciendo git pull antes de trabajar, realizando commits frecuentes y evitando modificar las mismas líneas en diferentes entornos.