resolve-git-conflicts
Acerca de
Esta habilidad de Claude ayuda a los desarrolladores a resolver conflictos de fusión y reorganización de Git con opciones de recuperación seguras. Identifica las fuentes de conflicto, lee los marcadores, ofrece estrategias de resolución y permite continuar o abortar las operaciones de manera segura. Úsala cuando las operaciones de git merge/rebase/cherry-pick/stash pop o pull reporten conflictos.
Instalación rápida
Claude Code
Recomendadonpx skills add pjt222/agent-almanac -a claude-code/plugin add https://github.com/pjt222/agent-almanacgit clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/resolve-git-conflictsCopia y pega este comando en Claude Code para instalar esta habilidad
Documentación
Resolve Git Conflicts
ID, resolve, recover from merge + rebase conflicts.
Use When
git mergeorgit rebasereports conflictsgit cherry-pickcan't apply cleanlygit pull→ conflictsgit stash popconflicts w/ working tree
In
- Required: Repo w/ active conflicts
- Optional: Preferred strategy (ours, theirs, manual)
- Optional: Ctx about which changes priority
Do
Step 1: ID Source
Determine what op caused conflict:
# 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
Status output tells which files have conflicts + active op.
→ git status shows files under "Unmerged paths" + indicates active op.
If err: git status clean tree but expected conflicts → op may have completed/aborted. Check git log recent activity.
Step 2: Read Markers
Open each conflicting file + locate markers:
<<<<<<< HEAD
// Your current branch's version
const result = calculateWeightedMean(data, weights);
=======
// Incoming branch's version
const result = computeWeightedAverage(data, weights);
>>>>>>> feature/rename-functions
<<<<<<< HEADto=======: Your current branch (or rebasing onto)=======to>>>>>>>: Incoming changes (merging branch or applying commit)
→ Each conflicting file has 1+ blocks w/ <<<<<<<, =======, >>>>>>> markers.
If err: no markers found but files conflicting → may be binary or deleted-vs-modified. Check git diff --name-only --diff-filter=U for full list.
Step 3: Choose Strategy
Manual merge (most common): Edit file to combine both changes logically, remove all markers.
Accept ours (keep current branch):
# 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
Accept theirs (keep incoming):
# 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
→ After resolution, file has correct merged content w/ no remaining markers.
If err: chose wrong side → re-read conflicting ver from merge base. During merge, git checkout -m path/to/file re-creates markers so you can try again.
Step 4: Mark Resolved
After editing each file:
# Stage the resolved file
git add path/to/resolved-file.R
# Check remaining conflicts
git status
Repeat for every file under "Unmerged paths".
→ All files move "Unmerged paths" → "Changes to be committed". No markers remain.
If err: git add fails or markers remain → re-open file + ensure all <<<<<<<, =======, >>>>>>> lines removed.
Step 5: Continue Op
Once all resolved:
For merge:
git commit
# Git auto-populates the merge commit message
For rebase:
git rebase --continue
# May encounter more conflicts on subsequent commits — repeat steps 2-4
For cherry-pick:
git cherry-pick --continue
For 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"
→ Op completes. git status shows clean tree (or moves to next commit during rebase).
If err: continue cmd fails → check git status for remaining unresolved. All conflicts must resolve before continuing.
Step 6: Abort if Needed
Resolution too complex or wrong approach → abort safely:
# Abort merge
git merge --abort
# Abort rebase
git rebase --abort
# Abort cherry-pick
git cherry-pick --abort
→ Repo returns to state before op started. No data loss.
If err: abort fails (rare) → check git reflog to find commit before op + git reset --hard <commit> to restore. Use w/ caution — discards uncommitted.
Step 7: Verify
After op completes:
# 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.)
→ Clean tree, correct merge history, tests pass.
If err: tests fail after resolution → merge may have introduced logical errs even though syntax conflicts resolved. Review diff carefully + fix.
Check
- No markers (
<<<<<<<,=======,>>>>>>>) remain -
git statusshows clean tree - Merge/rebase history correct in
git log - Tests pass after resolution
- No unintended changes introduced
Traps
- Blindly accept one side:
--ours/--theirsdiscards other side entirely. Only use when certain one ver completely correct. - Leave markers in code: Always search entire file for remaining markers after edit. Partial resolution breaks code.
- Amend during rebase: Interactive rebase → don't
--amendunless step specifically calls for it. Usegit rebase --continueinstead. - Lose work on abort:
git rebase --abort+git merge --abortdiscard all resolution work. Only abort to start over. - Not testing after resolution: Syntactically clean merge can still be logically wrong. Always run tests.
- Force-push after rebase: After rebasing shared branch, coord w/ collaborators before force-push, rewrites history.
→
commit-changes— committing after resolutionmanage-git-branches— branch workflows leading to conflictsconfigure-git-repository— repo setup + merge strategies
Repositorio GitHub
Habilidades relacionadas
executing-plans
DiseñoUtilice la habilidad executing-plans cuando tenga un plan de implementación completo para ejecutar en lotes controlados con puntos de revisión. Esta habilidad carga y revisa críticamente el plan, luego ejecuta tareas en pequeños lotes (por defecto 3 tareas) mientras reporta el progreso entre cada lote para la revisión del arquitecto. Esto asegura una implementación sistemática con puntos de control de calidad integrados.
requesting-code-review
DiseñoEsta habilidad despacha un subagente revisor de código para analizar los cambios en el código frente a los requisitos antes de proceder. Debe usarse después de completar tareas, implementar funciones principales o antes de fusionar con la rama principal. La revisión ayuda a detectar problemas de forma temprana al comparar la implementación actual con el plan original.
connect-mcp-server
DiseñoEsta habilidad proporciona una guía integral para que los desarrolladores conecten servidores MCP a Claude Code mediante transportes HTTP, stdio o SSE. Cubre la instalación, configuración, autenticación y seguridad para integrar servicios externos como GitHub, Notion y APIs personalizadas. Úsala al configurar integraciones MCP, al configurar herramientas externas o al trabajar con el Protocolo de Contexto del Modelo de Claude.
web-cli-teleport
DiseñoEsta habilidad ayuda a los desarrolladores a elegir entre las interfaces web y CLI de Claude Code mediante el análisis de tareas, y luego permite la teletransportación fluida de sesiones entre estos entornos. Optimiza el flujo de trabajo gestionando el estado y el contexto de la sesión al cambiar entre web, CLI o móvil. Úsala para proyectos complejos que requieren diferentes herramientas en varias etapas.
