/ 目錄 / 演練場 / Git
● 官方 modelcontextprotocol ⚡ 即開即用

Git

作者 modelcontextprotocol · modelcontextprotocol/servers

將 agent 指向本地儲存庫,讓它讀取狀態、日誌、差異與追蹤記錄——無需 shell 存取權限。

官方 modelcontextprotocol git 伺服器。讀寫本地 git:狀態、日誌、差異(已暫存/未暫存/提交範圍)、顯示、透過 show 輕量追蹤,以及支援寫入工作流程的提交/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 在提交前審查你的暫存變更

👤 獨立開發者、沒有程式碼審查流程的人 ⏱ ~3 min beginner

何時使用: 即將提交時。希望有第二雙眼睛在提交落地前發現明顯問題。

前置條件
  • 本地儲存庫含有已暫存的變更 — 照常執行 git add -p,然後詢問 agent
步驟
  1. 讀取已暫存的差異
    顯示我已暫存的變更。標記任何看起來像以下情況的內容:除錯日誌、被注釋掉的程式碼、硬編碼的機密資訊,或與提交目標「<GOAL>」無關的變更。✓ 已複製
    → 具體的 file:line 標記
  2. 建議提交訊息
    依照 conventional commits 規範撰寫提交訊息。第一行不超過 60 個字元,內文說明原因而非做了什麼。✓ 已複製
    → 可直接複製貼上的訊息
  3. 確認範圍
    根據差異,這次提交的範圍是否適當?若觸及多個關注點,請建議拆分方式。✓ 已複製
    → 附帶理由的通過/不通過結論

結果: 更乾淨的提交,減少後續「修漏」的提交次數。

注意事項
  • agent 因機密資訊外觀不明顯而漏判 — 不要將此作為機密掃描工具——在 pre-commit hook 中執行 gitleakstrufflehog 才是真正的防線
  • 先請 agent 撰寫提交訊息會讓它傾向核准差異 — 務必先完成審查步驟,再請 agent 撰寫訊息——順序很重要
搭配使用: github

找出某一行程式碼在何時、因何原因出錯

👤 除錯回歸問題的工程師 ⏱ ~15 min intermediate

何時使用: 某個測試開始失敗,需要找出是哪次提交引入了這個 bug。

步驟
  1. 縮小目標檔案的歷史範圍
    顯示 src/checkout/Cart.tsx 最近 20 次提交的 git log,包含作者與簡短訊息。✓ 已複製
    → 附有 SHA 的精簡歷史記錄
  2. 對可疑提交進行差異比較
    針對觸及 calculateTotal 函式的 3 次提交,顯示差異。聚焦於數學/邏輯變更,忽略風格調整。✓ 已複製
    → 每次提交的差異片段
  3. 形成回歸假設
    哪次提交最可能引入了差一錯誤或捨入 bug?請指出確切的行並說明理由。✓ 已複製
    → 附帶理由的具體 SHA + 行號

結果: 精確到提交層級的假設,可透過 git revert 加上重新執行測試來驗證。

注意事項
  • 大量重新命名的歷史記錄會在重新命名處斷失追蹤 — 採用 git log --follow 的思路——請 agent 納入重新命名該檔案的提交,並查看該提交重新命名前的路徑
搭配使用: github

列出並分類過時的本地分支

👤 任何 `git branch` 輸出多達好幾頁的人 ⏱ ~10 min beginner

何時使用: 季度性清理——分支太多,不確定哪些可以安全刪除。

步驟
  1. 列出所有本地分支
    列出每個本地分支及其最後一次提交的日期與訊息。✓ 已複製
    → 分支清單表格
  2. 對每個分支分類
    分類為:「已合併」(是 main 的祖先)、「過時」(60 天以上無提交)、「活躍」(30 天內有提交)。標記任何看起來像廢棄實驗的分支。✓ 已複製
    → 已分類的清單
  3. 提出刪除建議
    給我所有可以安全刪除的分支的 git branch -d 指令。標記任何需要 -D(強制)的分支並說明原因。✓ 已複製
    → 可直接複製貼上的清理指令

結果: 精簡過的分支清單,且有信心不會誤刪任何工作成果。

注意事項
  • agent 對實際上有 main 以外的唯一提交的分支建議 -D — 務必手動確認強制刪除清單——一次 git reflog 救回雖不貴,但很麻煩

組合

與其他 MCP 搭配,撬動十倍槓桿

git + github

推送前先在本地進行 git 審查,再用相同脈絡開立 PR

審查我已暫存的變更。若看起來沒問題,用描述性的訊息提交、推送分支,並在 GitHub 上開立 PR。✓ 已複製

在同一個推理迴圈中結合程式碼變更與 git 歷史記錄

讀取 src/auth/login.ts 以及最近 5 次觸及該檔案的提交。解釋為何加入了重試邏輯。✓ 已複製

工具

此 MCP 暴露的能力

工具輸入參數何時呼叫成本
git_status repo_path 任何工作階段的第一個呼叫——了解目前有哪些變更未提交 free
git_diff_unstaged repo_path, context_lines? 在執行 git add 前審查未暫存的變更 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 限制 token 用量 free
git_show repo_path, revision 檢視特定提交的詳細內容 free
git_commit repo_path, message 從已暫存的變更建立提交——唯讀設定請停用此工具 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? 列出分支,依包含某提交進行篩選 free

成本與限制

運行它的成本

API 配額
無——全部在本地執行
每次呼叫 Token 數
每次差異依大小約 200–5000 個 token
費用
免費
提示
大型差異會迅速消耗 token。請在提示中使用 context_lines: 1 或依路徑篩選,再讓 agent 讀取完整內容。

安全

權限、密鑰、影響範圍

憑證儲存: 無——不需要任何憑證
資料出站: 無——伺服器完全在本地執行,不進行任何網路呼叫

故障排查

常見錯誤與修復

fatal: not a git repository

--repository 路徑未指向 git 儲存庫。請執行 ls <path>/.git 確認——該目錄必須存在。

驗證: ls <repo_path>/.git/HEAD
Empty diff output despite uncommitted changes

請區分已暫存與未暫存——git_diff_unstagedgit_diff_staged 是兩個獨立工具。先用 git_status 確認各變更的位置。

git_commit fails with 'Please tell me who you are'

在儲存庫中設定 git config:執行 git config user.email ...git config user.name ...。MCP 使用你現有的 git 設定。

驗證: git config --get user.email
Huge diff burns tokens

傳入 context_lines: 0 或 1,或先請 agent 逐檔摘要後再讀取完整差異。

替代方案

Git 對比其他方案

替代方案何時用它替代權衡
GitHub MCP需要遠端歷史記錄(PR、審查留言、Actions),而不只是本地內容需要 PAT 並會進行網路呼叫;功能更強大,但攻擊面也更大
filesystem MCP + shell需要 git 以外的操作(grep、find、建置指令)影響範圍大幅擴大——若只需要 git 操作,請堅持使用 git MCP

更多

資源

📖 閱讀 GitHub 上的官方 README

🐙 查看未解決的 issue

🔍 瀏覽全部 400+ MCP 伺服器和 Skills