resolve-git-conflicts
정보
이 Claude Skill은 개발자가 Git 병합, 리베이스, 체리픽 충돌을 해결하도록 돕습니다. 충돌 원인을 식별하고, 마커를 읽으며, 해결 전략을 선택하는 방법을 제공합니다. 병합, 풀, 스태시 팝과 같은 명령어로 인해 충돌이 발생했을 때 작업을 계속하거나 중단하는 안전한 복구 방법도 제시합니다. 실패한 Git 작업을 체계적으로 처리하고 복구하는 데 활용하세요.
빠른 설치
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-conflictsClaude 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
디자인executing-plans 스킬은 검토 체크포인트가 포함된 통제된 배치로 실행할 완전한 구현 계획이 있을 때 사용합니다. 이 스킬은 계획을 불러와 비판적으로 검토한 후, 소규모 배치(기본값 3개 작업)로 작업을 실행하면서 각 배치 사이에 진행 상황을 아키텍트 검토를 위해 보고합니다. 이를 통해 내재된 품질 관리 체크포인트를 갖춘 체계적인 구현이 보장됩니다.
requesting-code-review
디자인이 스킬은 코드 변경 사항을 요구 사항에 따라 분석하기 위해 코드 리뷰어 하위 에이전트를 호출합니다. 작업 완료 후, 주요 기능 구현 후, 또는 메인 브랜치에 병합하기 전에 사용해야 합니다. 이 리뷰는 현재 구현체와 원래 계획을 비교하여 문제를 조기에 발견하는 데 도움이 됩니다.
connect-mcp-server
디자인이 스킬은 개발자들이 HTTP, stdio 또는 SSE 전송 방식을 통해 MCP 서버를 Claude Code에 연결하는 포괄적인 가이드를 제공합니다. GitHub, Notion 및 사용자 정의 API와 같은 외부 서비스를 통합하기 위한 설치, 구성, 인증 및 보안을 다룹니다. MCP 통합 설정, 외부 도구 구성 또는 Claude의 모델 컨텍스트 프로토콜 작업 시 활용하세요.
web-cli-teleport
디자인이 스킬은 작업 분석을 기반으로 개발자가 Claude Code 웹 인터페이스와 CLI 인터페이스 중 선택할 수 있도록 돕고, 두 환경 간 원활한 세션 텔레포트를 가능하게 합니다. 웹, CLI 또는 모바일 환경 전환 시 세션 상태와 컨텍스트를 관리하여 워크플로를 최적화합니다. 다양한 단계에서 서로 다른 도구가 필요한 복잡한 프로젝트에 사용하세요.
