Token导航 LogoToken导航

Agent Skill · 研究检索

resolve-git-conflicts(解决 git 冲突)

resolve-git-conflicts 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

resolve-git-conflicts 是研究检索类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为权限未标注;许可证信息还不明确,第三方扫描已通过,按安装量在研究检索类的 73,675 个 Skill 里排第 54,679。

总安装 499周安装 21GitHub Stars 12下载 175核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
unknown

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:resolve-git-conflicts(解决 git 冲突)
来源仓库:https://github.com/pjt222/development-guides
仓库路径:skills/resolve-git-conflicts
安装命令:
npx skills add https://github.com/pjt222/development-guides --skill resolve-git-conflicts
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/pjt222/development-guides --skill resolve-git-conflicts

这个 Skill 是做什么的

研究检索类 Skill 主要解决「找资料、核对事实、把来源整理清楚」的问题,通常会让助手先检索再总结。

查找、检索和筛选与 Git 冲突相关的信息。适合根据关键词快速定位候选解决方案。通过 npx skills add 命令从指定仓库安装并使用。需确认权限范围、维护状态,注意是否触发联网或命令执行。resolve-git-conflicts 属于研究检索类 Skill,可作为该场景下的辅助能力补充。

来源仓库内路径:skills/resolve-git-conflicts

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/pjt222/development-guides --skill resolve-git-…;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    权限没有明确标注,第一次使用时只给一个无关紧要的任务,观察它到底读了哪些文件和网络。

常见问题

6 条

resolve-git-conflicts 怎么安装?

在终端执行 npx skills add https://github.com/pjt222/development-guides --skill resolve-git-conflicts。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

resolve-git-conflicts 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

resolve-git-conflicts 需要什么权限?

权限级别没有明确标注。第一次使用时建议只给无关紧要的任务,观察它实际读写了哪些内容。

resolve-git-conflicts 是免费的吗?

公开资料没有标注明确许可证,收费和商用限制都无法确认。正式使用前请到来源仓库核对授权说明。

resolve-git-conflicts 用的人多吗?

公开数据是累计安装 499 次,近一周安装 21 次,下载 175 次,GitHub 12 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

resolve-git-conflicts 安全吗?

第三方扫描结果为通过,但这只覆盖已知的静态检查项,不能替代自己读一遍源码和安装命令。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 第三方扫描已通过,常见的高风险行为没有命中。

先想清楚的地方

  • 许可证没有明确标注,能不能商用、能不能再分发都不确定。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理研究检索类任务、又不想每次都手写提示词的人。

不太适合

  • 需要明确授权才能用到公司项目里的场景。
  • 需要厂商级技术支持和 SLA 的生产系统。

研究检索类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
find-skills

寻找技能 · Codex、Claude

31,199,81316,486操作浏览器MIT有提醒
self-improving-agent

自我改进 Agent · OpenClaw

16,464,0023,396接触敏感数据MIT-0通过
soultrace

灵魂追踪 · Codex、Claude

7,588,94412需要联网未明确有提醒
self-improving

自我完善 · OpenClaw

6,829,2841,046需要联网MIT-0通过
microsoft-foundry

微软代工厂 · Codex、Claude

6,614,144764调用外部服务未明确有提醒
resolve-git-conflicts

解决 git 冲突 · 本页

49912权限未标注未明确通过

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

Resolve Git Conflicts

Identify, resolve, and recover from merge and rebase conflicts.

When to Use

  • A git merge or git rebase reports conflicts
  • A git cherry-pick cannot apply cleanly
  • A git pull results in conflicting changes
  • A git stash pop conflicts 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.

Expected: git status shows files listed under "Unmerged paths" and indicates the active operation.

On failure: 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
  • <<<<<<< HEAD to =======: Your current branch (or the branch you're rebasing onto)
  • ======= to >>>>>>>: The incoming changes (the branch being merged or the commit being applied)

Expected: Each conflicting file contains one or more blocks with <<<<<<<, =======, and >>>>>>> markers.

On failure: 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

Expected: After resolution, the file contains the correct merged content with no remaining conflict markers.

On failure: 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".

Expected: All files move from "Unmerged paths" to "Changes to be committed". No conflict markers remain in any file.

On failure: 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"

Expected: The operation completes. git status shows a clean working tree (or moves to the next commit during rebase).

On failure: 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

Expected: Repository returns to the state before the operation started. No data loss.

On failure: 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.)

Expected: Clean working tree, correct merge history, tests pass.

On failure: 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 status shows a clean working tree
  • The merge/rebase history is correct in git log
  • Tests pass after conflict resolution
  • No unintended changes were introduced

Common Pitfalls

  • Blindly accepting one side: --ours or --theirs discards 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 --amend unless the rebase step specifically calls for it. Use git rebase --continue instead.
  • Losing work on abort: git rebase --abort and git merge --abort discard 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 resolution
  • manage-git-branches - branch workflows that lead to conflicts
  • configure-git-repository - repository setup and merge strategies

平台分布

Codex

33.75%
按下载量换算59

Claude

28.32%
按下载量换算50

Cursor

18.77%
按下载量换算33

Gemini CLI

9.35%
按下载量换算16

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

权限未标注

当前来源未能明确判断权限范围,默认进入异常复核队列。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills