Fix errors · How to use a skill

fix-git-conflicts

Resolves git conflicts hunk by hunk by first reading the commits, PRs and issues behind each side, keeping both intents where they fit, then running the project's checks and completing the merge or rebase. Use when git stopped with conflicts, a rebase is stuck, there are conflict markers in files, or the user asks to resolve merge conflicts.

Version 1.0 · Updated 2026-10-31

View raw SKILL.md

Install in Claude Code, Cursor or Codex (optional)

Only for AI coding tools that read skill folders. Run one line in a terminal, in your project folder. It downloads this skill's text files from TheSkillVault and nothing else; you can read them first with “View raw SKILL.md”.

Claude Code (all your projects)

curl -fsSL --create-dirs 'https://theskillvault.ai/api/skills/fix-git-conflicts/raw' -o ~/'.claude/skills/fix-git-conflicts/SKILL.md' && curl -fsSL --create-dirs 'https://theskillvault.ai/api/skills/fix-git-conflicts/files/LICENSE.txt' -o ~/'.claude/skills/fix-git-conflicts/LICENSE.txt'

Cursor (this project)

curl -fsSL --create-dirs 'https://theskillvault.ai/api/skills/fix-git-conflicts/raw' -o '.cursor/skills/fix-git-conflicts/SKILL.md' && curl -fsSL --create-dirs 'https://theskillvault.ai/api/skills/fix-git-conflicts/files/LICENSE.txt' -o '.cursor/skills/fix-git-conflicts/LICENSE.txt'

Codex and other Agent Skills tools (this project)

curl -fsSL --create-dirs 'https://theskillvault.ai/api/skills/fix-git-conflicts/raw' -o '.agents/skills/fix-git-conflicts/SKILL.md' && curl -fsSL --create-dirs 'https://theskillvault.ai/api/skills/fix-git-conflicts/files/LICENSE.txt' -o '.agents/skills/fix-git-conflicts/LICENSE.txt'

Or connect the whole library over MCP

Add TheSkillVault to Cursor or add this to your app's MCP settings (read-only; help):

{
  "mcpServers": {
    "theskillvault": {
      "url": "https://theskillvault.ai/mcp"
    }
  }
}

Fix git conflicts

A conflict is two people (or agents) changing the same lines for different reasons. Picking "ours" or "theirs" makes the markers go away but can silently drop someone's work. This skill reads why each side changed first, then keeps both intents where it can.

When to use

  • git merge, git rebase, git pull or git cherry-pick stopped with "CONFLICT".
  • Files contain <<<<<<<, ======= and >>>>>>> markers.
  • Parallel agents or branches touched the same files and now need to come together.

Steps

  1. See where you are. Run git status. Note the operation (merge, rebase or cherry-pick), the two branches and the conflicted files. For a rebase, note which commit is being replayed. In a rebase, "ours" is the branch you are rebasing onto, and "theirs" is your commit.
  2. Read the intent of each side. For each conflicted file, find the commits that changed it on both sides:
   git log --oneline --merge -- path/to/file
   git show <commit>

Read the commit messages, and the linked pull requests or issues if there are any. Write one line per side: what it was trying to do.

  1. Resolve hunk by hunk. For each conflict block:
  • If the intents fit together, keep both behaviours (for example, both new fields, both new imports).
  • If they truly clash, keep the side that matches the goal of this merge, and write down what was dropped and why.
  • Do not invent new behaviour that was on neither side just to make it compile.
  1. Check for hidden conflicts. Search the whole repo for leftover markers: git diff --check and grep -rn '^<<<<<<<\|^>>>>>>>' .. Look for code that merged cleanly but now calls something the other side renamed or removed.
  2. Run the project's checks. Find them in package.json, Makefile, CI config or AGENTS.md: format, lint, typecheck and tests. Run them now, before committing. Fix failures caused by the merge.
  3. Finish the operation. git add <files>, then git commit for a merge or git rebase --continue for a rebase. Repeat steps 1 to 5 for every remaining commit of a rebase until it completes.
  4. Report. For each file, say what each side wanted and how you combined them, and list anything dropped.

Gotchas

  • git checkout --ours or --theirs on a whole file throws away the other side completely. Use it only when you have checked that is right.
  • Lock files (package-lock.json, pnpm-lock.yaml) are better regenerated than hand-merged: take one side, then run the install command.
  • A merge that compiles can still break both branches' tests. Step 5 is not optional.
  • The session or person who wrote a change knows its intent best. If you can, let them resolve their own branch's conflicts.
  • Do large renames or refactors first, before other branches fork. Late refactors cause the most painful conflicts.

Safety

  • Do not run git merge --abort, git rebase --abort or git reset --hard on your own. They throw away resolution work. Abort only if the user decides the merge should not happen.
  • Never force-push a rebased shared branch without a clear yes from the user.
  • If a conflict is in a .env file or config with secrets, do not print the secret values in chat or logs.

Works with other tools

Git commands are the same in any editor and AI tool. VS Code, JetBrains and GitHub show a merge editor with the same "current" and "incoming" sides. Jujutsu (jj) or another version control tool records conflicts differently, but the same rule applies: read the intent, keep both, run the checks.

Done when

  • git status shows no conflicts and the merge or rebase is complete.
  • No conflict markers remain anywhere in the repo.
  • The project's checks passed on the merged code, and you reported what each side kept or dropped.

Example prompt

"My rebase onto main stopped with conflicts in three files. Resolve them without losing either side's changes, run the tests and finish the rebase."

---

Adapted from "resolving-merge-conflicts" in mattpocock/skills by Matt Pocock (MIT). See LICENSE.txt.

Adapted from Matt Pocock (mattpocock/skills, 'resolving-merge-conflicts') (Copyright (c) 2026 Matt Pocock), MIT License. Adapted by TheSkillVault from the archived skill's documentation page: turned into numbered steps with git commands; kept the read-the-intent and run-the-checks rules; replaced 'never abort' with 'abort only if the user decides not to merge'; added safety, gotchas, portability and done-when sections.

Licence: MIT License. Attribution when you reuse it: Based on work by Matt Pocock (mattpocock/skills, 'resolving-merge-conflicts') (Copyright (c) 2026 Matt Pocock, MIT License), https://github.com/mattpocock/skills/blob/a496f5513d4a4cf889bc48e189e579f4b0bdf6aa/docs/engineering/resolving-merge-conflicts.md; adapted by TheSkillVault, https://theskillvault.ai