mcpField
G
git-master

git-master

github.com/code-yeongyu开发70.8k124 次安装今天更新
代码仓库

关于 git-master

供 Agent 处理提交、历史改写、仓库状态和历史调查的 Git Skill。它先区分操作类型，再要求基于证据检查，并在改写历史前执行安全核验。

主要功能

  1. 01区分 Git 操作模式
  2. 02检查仓库状态与历史
  3. 03指导原子化提交
  4. 04设置变基安全措施
  5. 05要求历史问题提供证据

适用场景

  1. 01提交指定更改并保留无关改动
  2. 02安全变基或重组分支历史
  3. 03查明某项更改何时或何处进入历史

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/code-yeongyu/oh-my-openagent --skill git-master

安装后在 Claude Code 中输入/git-master确认已加载。

附带文件agents/openai.yaml

详细介绍

Git Master

当用户要求你操作 Git 历史或回答有关 Git 历史的问题时，请使用此技能。务必准确、谨慎，并以证据为依据。做出任何推断前，先检查仓库状态。

模式判定

首先对请求进行分类：

  • COMMIT：暂存并提交本地更改。
  • REBASE：变基、压缩、修正、自动压缩、重排、拆分或以其他方式改写分支历史。
  • HISTORY：回答何时、何处、谁、为何或哪个提交更改了某项内容。
  • STATUS：检查分支、差异或工作区状态，但不做任何更改。

除非用户明确要求执行相应操作，否则不得提交、变基、推送、强制推送、重置、弹出暂存内容或删除任何内容。如果请求仅用于调查，则报告调查结果并停止。

事实依据

如果工具支持，请并行收集相互独立的事实：

git status --short
git diff --stat
git diff --staged --stat
git branch --show-current
git log -30 --oneline
git log -30 --pretty=format:%s
git rev-parse --abbrev-ref @{upstream}
git merge-base HEAD origin/main
git merge-base HEAD origin/master

缺少上游分支或缺少 main/master 都是正常情况。请回退到最合适的可用分支，或说明缺少该事实。绝不能把查询失败当作证据。

PR 正文证据附件

当 PR 正文需要截图或终端 PNG 时，请参阅仓库中的 docs/reference/github-attachment-upload.md。允许的托管方式是通过已认证的网页附件流程上传到 GitHub 用户附件；绝不能提交临时图片，绝不能使用 GitHub Releases 作为 PR 证据，也绝不能使用外部图床。不要记录浏览器 Cookie、CSRF 令牌、S3 表单字段或上传请求头。

提交模式

仅提交用户要求提交的更改。保留无关的未提交工作。

  1. 从近期历史中识别提交消息风格。使用占主导地位的本地格式、语言和大小写习惯。除非仓库使用 Conventional Commits，否则不要默认采用该格式。
  2. 检查完整差异，而不仅是文件名。将无关的用户编辑与用户要求提交的内容分开。
  3. 按行为、模块和可还原性划分原子组。将实现及其直接相关的测试放在一起。
  4. 对无关事项优先使用多个提交。只有当更改的文件构成不可拆分的单一行为，或用户明确要求一个提交时，才使用单个提交。
  5. 按路径或代码块暂存，确保每个提交仅包含对应的原子组。
  6. 每次提交前，检查 git diff --staged --stat，并查看足够的已暂存差异，以确认提交组正确。
  7. 按识别出的风格提交。每次提交后，检查 git log -1 --oneline。

分组规则：

  • 将不同的功能、模块、生成文件、配置、文档和仅涉及测试的更改拆分，除非它们不可分割。
  • 如果省略生成文件会导致仓库不一致，则将生成文件与生成它的源代码更改放在一起。
  • 绝不要将失败的更改或无关更改隐藏在一个宽泛的提交中。

最终报告：列出提交哈希、消息，以及任何剩余的未提交文件。

变基模式

改写历史会影响其他人。

  • 除非用户明确指定对 main、master、dev、发布分支或受保护分支执行该操作，否则绝不要对其进行变基或改写。
  • 如果提交可能已经推送，强制推送前先询问。使用 --force-with-lease，绝不要使用普通的 --force。
  • 如果工作区有未提交更改，请在变基前有意妥善保留。解决冲突前，不要直接弹出暂存内容。
  • 对于修正提交，优先使用 git commit --fixup=<hash>，然后执行 GIT_SEQUENCE_EDITOR=: git rebase -i --autosquash <base>。
  • 遇到冲突时，先阅读冲突文件，并根据意图解决。不要盲目选择 ours/theirs。
  • 如果变基出错，首先使用 git rebase --abort。只有在说明恢复路径后，才使用 reflog。

改写历史后，运行相关测试，或至少运行项目中开销最低的冒烟检查，然后展示从基点到 HEAD 的新分支日志。

历史模式

根据问题选择 Git 工具：

  • git log -S "text"：精确字符串的出现次数发生变化时使用。
  • git log -G "regex"：差异中有行匹配某个模式时使用。
  • git blame -L start,end -- file：查看特定行最近由谁修改。
  • git log --follow -- file：查看单个文件改名前后的历史。
  • git show <hash>：检查看起来相关的提交。
  • git bisect：存在确定性的通过／失败命令且已知良好和不良提交范围时，查找第一个不良提交。
  • git reflog：恢复或说明近期本地历史记录的变动。

回答时始终引用确切的命令证据：提交哈希、主题、文件路径，以及相关的行或差异上下文。如果证据有歧义，请说明哪些内容仍未得到证实。

安全检查

对 Git 历史进行任何写入操作之前：

  • 确认当前分支。
  • 确认并妥善处理未提交的改动。
  • 确认上游／推送状态；若未知，则明确说明。
  • 确认操作符合用户的请求。
  • 确认恢复方案（rebase --abort、reflog 哈希或未改动的工作树）。

完成之前：

  • 针对已更改的行为或历史操作，运行最相关的验证。
  • 报告通过的命令，以及无法运行的命令。
  • 明确说明工作树状态。

评论

支持 Markdown