/ 目录 / 演练场 / Git
● 官方 modelcontextprotocol ⚡ 即开即用

Git

作者 modelcontextprotocol · modelcontextprotocol/servers

将你的 agent 指向本地仓库,让它读取状态、日志、diff 和 blame 信息——无需 shell 访问权限。

官方 modelcontextprotocol git 服务器。读写本地 git:status、log、diff(staged/unstaged/commit-range)、show、blame-lite via show,以及 commit/add/branch/checkout 用于支持写入的工作流。限制在单个 --repository 路径——比给 agent 原始 shell 访问权更安全。

为什么要用

核心特性

实时演示

实际使用效果

git.replay ▶ 就绪
0/0

安装

选择你的客户端

~/Library/Application Support/Claude/claude_desktop_config.json  · Windows: %APPDATA%\Claude\claude_desktop_config.json
{
  "mcpServers": {
    "git": {
      "command": "uvx",
      "args": [
        "mcp-server-git",
        "--repository",
        "/repo"
      ]
    }
  }
}

打开 Claude Desktop → Settings → Developer → Edit Config。保存后重启应用。

~/.cursor/mcp.json · .cursor/mcp.json
{
  "mcpServers": {
    "git": {
      "command": "uvx",
      "args": [
        "mcp-server-git",
        "--repository",
        "/repo"
      ]
    }
  }
}

Cursor 使用与 Claude Desktop 相同的 mcpServers 格式。项目级配置优先于全局。

VS Code → Cline → MCP Servers → Edit
{
  "mcpServers": {
    "git": {
      "command": "uvx",
      "args": [
        "mcp-server-git",
        "--repository",
        "/repo"
      ]
    }
  }
}

点击 Cline 侧栏中的 MCP Servers 图标,然后选 "Edit Configuration"。

~/.codeium/windsurf/mcp_config.json
{
  "mcpServers": {
    "git": {
      "command": "uvx",
      "args": [
        "mcp-server-git",
        "--repository",
        "/repo"
      ]
    }
  }
}

格式与 Claude Desktop 相同。重启 Windsurf 生效。

~/.continue/config.json
{
  "mcpServers": [
    {
      "name": "git",
      "command": "uvx",
      "args": [
        "mcp-server-git",
        "--repository",
        "/repo"
      ]
    }
  ]
}

Continue 使用服务器对象数组,而非映射。

~/.config/zed/settings.json
{
  "context_servers": {
    "git": {
      "command": {
        "path": "uvx",
        "args": [
          "mcp-server-git",
          "--repository",
          "/repo"
        ]
      }
    }
  }
}

加入 context_servers。Zed 保存后热重载。

claude mcp add git -- uvx mcp-server-git --repository /repo

一行命令搞定。用 claude mcp list 验证,claude mcp remove 卸载。

使用场景

实战用法: Git

在提交前让 agent 审查你的 staged 变更

👤 独立开发者,任何在没有代码审查的情况下发布的人 ⏱ ~3 min beginner

何时使用: 即将提交。希望有第二双眼睛在提交落地之前捕捉明显的问题。

前置条件
  • 带有 staged 变更的本地仓库 — 照常使用 git add -p,然后询问 agent
步骤
  1. 读取 staged diff
    给我展示我的 staged 变更。标记任何看起来像:调试日志、注释代码、硬编码的密钥或与声明的提交目标 '<GOAL>' 无关的变更的东西。✓ 已复制
    → 特定文件:行 标记
  2. 建议一条 commit 消息
    编写遵循 conventional commits 的 commit 消息。首行少于 60 个字符,正文解释为什么而不是什么。✓ 已复制
    → 可复制粘贴的消息
  3. 确认范围
    根据 diff,这个 commit 足够小吗?如果涉及多个关注点,建议进行拆分。✓ 已复制
    → Go/no-go 和原因说明

结果: 一个更干净的 commit,更少的 'oops' 后续。

注意事项
  • Agent 遗漏了密钥,因为它们看起来不像明显的密钥形状 — 不要将其作为密钥扫描器——在你的 pre-commit hook 中运行 gitleakstrufflehog 作为真正的防御
  • 要求 commit 消息会偏向 agent 批准 diff — 总是在要求消息之前进行审查步骤——顺序很重要
搭配使用: github

找出何时以及为什么某一特定行损坏

👤 调试回归的工程师 ⏱ ~15 min intermediate

何时使用: 一个测试开始失败,你需要知道哪个 commit 引入了这个 bug。

步骤
  1. 缩小嫌疑文件的历史范围
    显示 src/checkout/Cart.tsx 的 git log,限制在最后 20 个 commit。包括作者和短消息。✓ 已复制
    → 带有 SHA 的紧凑历史
  2. 对比嫌疑 commit
    对于接触 calculateTotal 函数的 3 个 commit,展示 diff。重点关注数学/逻辑变更,忽略风格。✓ 已复制
    → 每个 commit 的 diff 片段
  3. 形成回归假设
    哪个 commit 最有可能引入了 off-by-one 或舍入 bug?指出确切的行并解释你的推理。✓ 已复制
    → 特定 SHA + 行及原因说明

结果: 一个精确的 commit 级假设,你可以通过 git revert + 重新运行测试来确认。

注意事项
  • 重命名繁重的历史在重命名处丢失跟踪 — 使用 git log --follow 的思维——要求 agent 包括重命名文件的 commit,并查看该 commit 的重命名前路径
搭配使用: github

列出并分类陈旧的本地分支

👤 任何 `git branch` 输出很长的人 ⏱ ~10 min beginner

何时使用: 季度清理——太多分支,不清楚哪些可以安全删除。

步骤
  1. 列出所有本地分支
    列出每个本地分支及其最后提交日期和消息。✓ 已复制
    → 分支表
  2. 对每个进行分类
    分类:'merged'(main 的祖先)、'stale'(60+ 天内没有 commit)、'active'(最后 30 天内有 commit)。标记任何看起来像被遗弃的实验的。✓ 已复制
    → 分类列表
  3. 提议删除
    给我 git branch -d 命令以删除所有安全的内容。标记任何需要 -D(强制)的内容并解释原因。✓ 已复制
    → 可复制粘贴的清理命令

结果: 一个精简的分支列表,确信你不会丢弃工作。

注意事项
  • Agent 为实际上有不在 main 上的唯一 commit 的分支建议 -D — 总是手动检查强制删除列表——一次 git reflog 恢复很便宜但令人烦恼

组合

与其他 MCP 搭配,撬动十倍杠杆

git + github

推送前的本地 git 审查,然后在同一上下文中打开 PR

审查我的 staged 变更。如果看起来不错,使用描述性消息进行 commit,推送分支,并在 GitHub 上打开 PR。✓ 已复制

在一个推理循环中进行代码变更 + git 历史

读取 src/auth/login.ts 和最后 5 个接触它的 commit。解释为什么添加了重试逻辑。✓ 已复制

工具

此 MCP 暴露的能力

工具输入参数何时调用成本
git_status repo_path 任何会话的首次调用——理解什么是脏的 free
git_diff_unstaged repo_path, context_lines? git add 之前审查未 staged 的变更 free
git_diff_staged repo_path, context_lines? 审查即将被提交的内容 free
git_diff repo_path, target, context_lines? 将当前分支与目标进行比较(例如 main、HEAD~5) free
git_log repo_path, max_count?, start_timestamp?, end_timestamp? 历史浏览——与 max_count 配对以限制令牌使用 free
git_show repo_path, revision 检查特定的 commit free
git_commit repo_path, message 从 staged 变更创建一个 commit——在只读设置中禁用 free
git_add repo_path, files: string[] 暂存特定文件——为了 agent 安全,优先于 git_add . free
git_reset repo_path 取消暂存一切——危险,通常跳过 free
git_create_branch repo_path, branch_name, base_branch? 为一个任务开始一个新分支 free
git_checkout repo_path, branch_name 切换分支 free
git_branch repo_path, branch_type, contains?, not_contains? 列出分支,按包含 commit 进行过滤 free

成本与限制

运行它的成本

API 配额
无——全部本地
每次调用 Token 数
200–5000 每个 diff 取决于大小
费用
免费
提示
大型 diff 快速消耗令牌成本。在要求 agent 读取整个内容之前,使用 context_lines: 1 或在你的提示中按路径过滤。

安全

权限、密钥、影响范围

凭据存储: 无——无凭据
数据出站: 无——服务器 100% 本地,无网络调用

故障排查

常见错误与修复

fatal: not a git repository

--repository 路径没有指向 git 仓库。使用 ls <path>/.git 进行验证——目录必须存在。

验证: ls <repo_path>/.git/HEAD
尽管有未提交的变更,diff 输出为空

检查 staged 与 unstaged——git_diff_unstagedgit_diff_staged 是单独的工具。首先使用 git_status 查看什么在哪里。

git_commit 失败,提示 'Please tell me who you are'

在仓库中设置 git config:git config user.email ...git config user.name ...。MCP 使用你现有的 git config。

验证: git config --get user.email
巨大的 diff 消耗令牌

传递 context_lines: 0 或 1,或在读取完整 diff 之前要求 agent 首先逐文件总结。

替代方案

Git 对比其他方案

替代方案何时用它替代权衡
GitHub MCP你想要远程历史(PR、审查注释、Actions)而不仅仅是本地需要 PAT 并进行网络调用;功能更强大但攻击面更大
filesystem MCP + shell你需要超出 git 的操作(grep、find、build 命令)影响范围大得多——如果你只需要 git,坚持使用 git MCP

更多

资源

📖 阅读 GitHub 上的官方 README

🐙 查看未解决的 issue

🔍 浏览全部 400+ MCP 服务器和 Skills