resolve-git-conflicts
关于
This Claude Skill helps developers resolve Git merge, rebase, and cherry-pick conflicts by identifying conflict sources, reading markers, and choosing resolution strategies. It provides safe recovery methods for continuing or aborting operations when conflicts arise from commands like merge, pull, or stash pop. Use it to systematically handle and recover from failed Git operations.
快速安装
Claude Code
推荐npx 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-conflicts在 Claude Code 中复制并粘贴此命令以安装该技能
技能文档
Resolve Git Conflicts
Identify, resolve, and recover from merge and rebase conflicts.
When to Use
- A
git mergeorgit rebasereports conflicts - A
git cherry-pickcannot apply cleanly - A
git pullresults in conflicting changes - A
git stash popconflicts with current working tree
Inputs
- Required: Repository with active conflicts
- Optional: Preferred resolution strategy (ours, theirs, manual)
- Optional: Context about which changes should take priority
Procedure
Step 1: Identify the Conflict Source
Determine what operation caused the 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
The status output tells you which files have conflicts and what operation is in progress.
Got: git status shows files listed under "Unmerged paths" and indicates the active operation.
If fail: If git status shows a clean tree but you expected conflicts, the operation may have already been completed or aborted. Check git log for recent activity.
Step 2: Read Conflict Markers
Open each conflicting file and locate the conflict 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 the branch you're rebasing onto)=======to>>>>>>>: The incoming changes (the branch being merged or the commit being applied)
Got: Each conflicting file contains one or more blocks with <<<<<<<, =======, and >>>>>>> markers.
If fail: If no markers are found but files show as conflicting, the conflict may be a binary file or a deleted-vs-modified conflict. Check git diff --name-only --diff-filter=U for the full list.
Step 3: Choose a Resolution Strategy
Manual merge (most common): Edit the file to combine both changes logically, then remove all conflict markers.
Accept ours (keep current branch's version):
# 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 branch's version):
# 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
Got: After resolution, the file contains the correct merged content with no remaining conflict markers.
If fail: If you chose the wrong side, re-read the conflicting version from the merge base. During a merge, git checkout -m path/to/file re-creates the conflict markers so you can try again.
Step 4: Mark Files as Resolved
After editing each conflicting file:
# Stage the resolved file
git add path/to/resolved-file.R
# Check remaining conflicts
git status
Repeat for every file listed under "Unmerged paths".
Got: All files move from "Unmerged paths" to "Changes to be committed". No conflict markers remain in any file.
If fail: If git add fails or markers remain, re-open the file and ensure all <<<<<<<, =======, and >>>>>>> lines are removed.
Step 5: Continue the Operation
Once all conflicts are 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"
Got: The operation completes. git status shows a clean working tree (or moves to the next commit during rebase).
If fail: If the continue command fails, check git status for remaining unresolved files. All conflicts must be resolved before continuing.
Step 6: Abort if Needed
If resolution is too complex or you chose the wrong approach, abort safely:
# Abort merge
git merge --abort
# Abort rebase
git rebase --abort
# Abort cherry-pick
git cherry-pick --abort
Got: Repository returns to the state before the operation started. No data loss.
If fail: If abort fails (rare), check git reflog to find the commit before the operation and git reset --hard <commit> to restore it. Use with caution — this discards uncommitted changes.
Step 7: Verify Resolution
After the operation 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.)
Got: Clean working tree, correct merge history, tests pass.
If fail: If tests fail after resolution, the merge may have introduced logical errors even though syntax conflicts are resolved. Review the diff carefully and fix.
Validation
- No conflict markers (
<<<<<<<,=======,>>>>>>>) remain in any file -
git statusshows a clean working tree - The merge/rebase history is correct in
git log - Tests pass after conflict resolution
- No unintended changes were introduced
Pitfalls
- Blindly accepting one side:
--oursor--theirsdiscards the other side entirely. Only use when you are certain one version is completely correct. - Leaving conflict markers in code: Always search the entire file for remaining markers after editing. A partial resolution breaks the code.
- Amending during rebase: During an interactive rebase, do not
--amendunless the rebase step specifically calls for it. Usegit rebase --continueinstead. - Losing work on abort:
git rebase --abortandgit merge --abortdiscard all resolution work. Only abort if you want to start over. - Not testing after resolution: A syntactically clean merge can still be logically wrong. Always run tests.
- Force-pushing after rebase: After rebasing a shared branch, coordinate with collaborators before force-pushing, as it rewrites history.
Related Skills
commit-changes- committing after conflict resolutionmanage-git-branches- branch workflows that lead to conflictsconfigure-git-repository- repository setup and merge strategies
GitHub 仓库
相关推荐技能
executing-plans
设计该Skill用于当开发者提供完整实施计划时,以受控批次方式执行代码实现。它会先审阅计划并提出疑问,然后分批次执行任务(默认每批3个任务),并在批次间暂停等待审查。关键特性包括分批次执行、内置检查点和架构师审查机制,确保复杂系统实现的可控性。
requesting-code-review
设计该Skill可在完成任务、实现主要功能或合并代码前自动调度代码审查子代理,确保实现符合需求和计划。它支持通过指定git SHA范围进行精准的代码变更审查,帮助开发者在关键节点及时发现潜在问题。核心原则是"早审查、勤审查",适用于开发流程的各个关键阶段。
connect-mcp-server
设计这个Skill指导开发者如何将MCP服务器连接到Claude Code,支持HTTP、stdio和SSE三种传输协议。它涵盖了从安装配置到认证安全的完整流程,适用于集成GitHub、Notion、数据库等外部服务。当开发者需要添加集成、配置外部工具或提及MCP相关功能时,这个Skill能提供实用的操作指南。
web-cli-teleport
设计该Skill帮助开发者根据任务特性选择Claude Code的Web或CLI界面,并指导如何在两种环境间无缝迁移会话。它能分析任务复杂度、迭代需求等要素,推荐最优工作界面和工作流。关键特性包括会话状态管理、环境切换指导和上下文优化建议。
