---

name: resolve-git-conflicts description: > Resuelve conflictos de merge y rebase con estrategias seguras de recuperación. Cubre la identificación de fuentes de conflicto, lectura de marcadores de conflicto, elección de estrategias de resolución y cómo continuar o abortar operaciones de forma segura. Úsalo cuando un git merge, rebase, cherry-pick o stash pop reporte conflictos, cuando un git pull resulte en cambios conflictivos, o cuando necesites abortar y reiniciar de forma segura una operación de merge o rebase fallida. license: MIT allowed-tools: Read Write Edit Bash Grep Glob metadata: author: Philipp Thoss version: "1.0" domain: git complexity: intermediate language: multi tags: git, merge-conflicts, rebase, conflict-resolution, version-control locale: es source_locale: en source_commit: 6f65f316 fence_basis_commit: 6f65f316 translator: claude-opus-4-6 translation_date: 2026-03-16

Resolver Conflictos Git

Identifica, resuelve y recupera conflictos de merge y rebase.

Cuándo Usar

• Un git merge o git rebase reporta conflictos
• Un git cherry-pick no puede aplicarse limpiamente
• Un git pull resulta en cambios conflictivos
• Un git stash pop entra en conflicto con el árbol de trabajo actual

Entradas

• Requerido: Repositorio con conflictos activos
• Opcional: Estrategia de resolución preferida (ours, theirs, manual)
• Opcional: Contexto sobre qué cambios deben tener prioridad

Procedimiento

Paso 1: Identificar la Fuente del Conflicto

Determina qué operación causó el conflicto:

# Check current status
git status

# Look for indicators:
# "You have unmerged paths" — merge conflict
# "rebase in progress" — rebase conflict
# "cherry-pick in progress" — cherry-pick conflict

La salida del estado te indica qué archivos tienen conflictos y qué operación está en curso.

Esperado: git status muestra archivos listados bajo "Unmerged paths" e indica la operación activa.

En caso de fallo: Si git status muestra un árbol limpio pero esperabas conflictos, la operación puede haberse completado o abortado ya. Revisa git log para ver la actividad reciente.

Paso 2: Leer los Marcadores de Conflicto

Abre cada archivo en conflicto y localiza los marcadores de conflicto:

<<<<<<< HEAD
// Your current branch's version
const result = calculateWeightedMean(data, weights);
=======
// Incoming branch's version
const result = computeWeightedAverage(data, weights);
>>>>>>> feature/rename-functions

• De <<<<<<< HEAD a =======: Tu rama actual (o la rama sobre la que estás haciendo rebase)
• De ======= a >>>>>>>: Los cambios entrantes (la rama que se fusiona o el commit que se aplica)

Esperado: Cada archivo en conflicto contiene uno o más bloques con marcadores <<<<<<<, ======= y >>>>>>>.

En caso de fallo: Si no se encuentran marcadores pero los archivos aparecen como conflictivos, el conflicto puede ser un archivo binario o un conflicto de archivo eliminado vs. modificado. Revisa git diff --name-only --diff-filter=U para la lista completa.

Paso 3: Elegir una Estrategia de Resolución

Merge manual (más común): Edita el archivo para combinar lógicamente ambos cambios, luego elimina todos los marcadores de conflicto.

Aceptar los nuestros (conservar la versión de la rama actual):

# For a single file
git checkout --ours path/to/file.R
git add path/to/file.R

# For all conflicts
git checkout --ours .
git add -A

Aceptar los suyos (conservar la versión de la rama entrante):

# For a single file
git checkout --theirs path/to/file.R
git add path/to/file.R

# For all conflicts
git checkout --theirs .
git add -A

Esperado: Tras la resolución, el archivo contiene el contenido fusionado correcto sin marcadores de conflicto restantes.

En caso de fallo: Si elegiste el lado equivocado, vuelve a leer la versión en conflicto desde la base de la fusión. Durante un merge, git checkout -m path/to/file recrea los marcadores de conflicto para que puedas intentarlo de nuevo.

Paso 4: Marcar Archivos como Resueltos

Después de editar cada archivo en conflicto:

# Stage the resolved file
git add path/to/resolved-file.R

# Check remaining conflicts
git status

Repite para cada archivo listado bajo "Unmerged paths".

Esperado: Todos los archivos pasan de "Unmerged paths" a "Changes to be committed". No quedan marcadores de conflicto en ningún archivo.

En caso de fallo: Si git add falla o quedan marcadores, vuelve a abrir el archivo y asegúrate de que todas las líneas <<<<<<<, ======= y >>>>>>> fueron eliminadas.

Paso 5: Continuar la Operación

Una vez resueltos todos los conflictos:

Para merge:

git commit
# Git auto-populates the merge commit message

Para rebase:

git rebase --continue
# May encounter more conflicts on subsequent commits — repeat steps 2-4

Para cherry-pick:

git cherry-pick --continue

Para stash pop:

# Stash pop conflicts don't need a continue — just commit or reset
git add .
git commit -m "Apply stashed changes with conflict resolution"

Esperado: La operación se completa. git status muestra un árbol de trabajo limpio (o avanza al siguiente commit durante el rebase).

En caso de fallo: Si el comando continue falla, revisa git status en busca de archivos no resueltos. Todos los conflictos deben estar resueltos antes de continuar.

Paso 6: Abortar si es Necesario

Si la resolución es demasiado compleja o elegiste el enfoque equivocado, aborta de forma segura:

# Abort merge
git merge --abort

# Abort rebase
git rebase --abort

# Abort cherry-pick
git cherry-pick --abort

Esperado: El repositorio vuelve al estado anterior al inicio de la operación. Sin pérdida de datos.

En caso de fallo: Si el abort falla (poco frecuente), revisa git reflog para encontrar el commit anterior a la operación y usa git reset --hard <commit> para restaurarlo. Úsalo con precaución — esto descarta los cambios sin commit.

Paso 7: Verificar la Resolución

Después de que la operación se complete:

# Verify clean working tree
git status

# Check that the merge/rebase result is correct
git log --oneline -5
git diff HEAD~1

# Run tests to confirm nothing is broken
# (language-specific: devtools::test(), npm test, cargo test, etc.)

Esperado: Árbol de trabajo limpio, historial de merge correcto, pruebas pasan.

En caso de fallo: Si las pruebas fallan tras la resolución, el merge puede haber introducido errores lógicos aunque los conflictos sintácticos estén resueltos. Revisa el diff detenidamente y corrige.

Validación

• No quedan marcadores de conflicto (<<<<<<<, =======, >>>>>>>) en ningún archivo
• git status muestra un árbol de trabajo limpio
• El historial de merge/rebase es correcto en git log
• Las pruebas pasan después de la resolución de conflictos
• No se introdujeron cambios no intencionados

Errores Comunes

• Aceptar ciegamente un lado: --ours o --theirs descarta completamente el otro lado. Úsalo solo cuando tengas la certeza de que una versión es completamente correcta.
• Dejar marcadores de conflicto en el código: Busca siempre en todo el archivo marcadores restantes después de editar. Una resolución parcial rompe el código.
• Hacer amend durante el rebase: Durante un rebase interactivo, no uses --amend a menos que el paso del rebase lo indique expresamente. Usa git rebase --continue en su lugar.
• Perder trabajo al abortar: git rebase --abort y git merge --abort descartan todo el trabajo de resolución. Solo aborta si quieres empezar de nuevo.
• No probar después de la resolución: Un merge sintácticamente correcto puede seguir siendo lógicamente incorrecto. Ejecuta siempre las pruebas.
• Forzar push después del rebase: Tras hacer rebase de una rama compartida, coordina con los colaboradores antes de forzar el push, ya que reescribe el historial.

Habilidades Relacionadas

• commit-changes - hacer commit después de resolver conflictos
• manage-git-branches - flujos de trabajo de ramas que llevan a conflictos
• configure-git-repository - configuración del repositorio y estrategias de merge