版本控制工具

一个为AI编程代理提供Git版本控制操作的MCP服务器,支持LangChain等MCP兼容的LLM工作流。

  • by archish9
  • Python
  • 本地部署
  • 更新于
在 GitHub 查看 archish9/github-mcp-small

使用说明

版本控制助手

A. 模型上下文协议(MCP) 服务器提供版本控制操作作为AI编码代理的工具。专为与LangChain深度代理和其他兼容MCP的LLM工作流集成而构建。

这是什么?

此MCP服务器公开 Git版本控制操作 作为大型语言模型(LLM)和AI代理可以编程调用的结构化工具。AI编码代理可以调用类型化的、经过验证的工具,而不是执行原始的git命令,例如 commit_all_changes, rollback_to_commit,或 compare_commits 通过标准化的MCP协议。

为什么使用这个?

问题 解决方案
AI代理生成没有版本历史的代码 每次代码更改都可以自动提交
糟糕的AI生成代码会破坏项目 立即回滚到任何先前的提交
无法查看代理更改了什么 比较任意两个提交以查看确切的差异
在代理迭代过程中丢失工作的风险 分支允许安全的实验

安装

先决条件

  • Python 3.11+
  • 紫外线 包管理器
  • 系统上已安装Git

设置

# Clone the repository
git clone https://github.com/your-repo/VersionControlHelperMCP.git
cd VersionControlHelperMCP

# Install dependencies with uv
uv sync

运行服务器

STDIO模式(默认)

对于LangChain或其他MCP客户端的本地使用:

uv run version-control-helper-mcp

使用默认存储库路径

集 REPO_PATH 避免超车 repo_path 在每次工具调用中:

REPO_PATH=/path/to/your/project uv run version-control-helper-mcp

开发/调试

使用MCP检查员进行测试:

uv run mcp dev src/version_control_helper_mcp/server.py

可用工具

此服务器提供 10工具 用于完整的版本控制工作流。

1. initialize_repo

目的:初始化一个新的git仓库或验证一个现有的仓库。

参数 类型 必填 默认 说明
repo_path string ✅ - 存储库目录的绝对路径
initial_commit boolean ❌ true 使用README创建初始提交

退货:状态消息(例如,“初始提交的已初始化存储库:abc1234”)

何时使用:

  • 从头开始一个新项目
  • 在对新目录执行任何其他git操作之前
  • 可以安全地调用已初始化的存储库(将返回“已初始化”)

示例:

{
  "tool": "initialize_repo",
  "arguments": {
    "repo_path": "/Users/dev/my-project",
    "initial_commit": true
  }
}

2. get_repo_status

目的:检查存储库的当前状态。

参数 类型 必填 说明
repo_path string ✅ 存储库的绝对路径

退货:JSON对象,具有:

  • is_initialized:是否设置了git
  • current_branch:活动分支名称
  • has_changes:是否有未提交的更改
  • staged_files:文件已准备好提交
  • modified_files:已更改但未暂存的文件
  • untracked_files:尚未跟踪的新文件

何时使用:

  • 在承诺之前,看看会包括什么
  • 更改后,验证修改
  • 检查您所在的分支机构

3. commit_all_changes

目的:执行所有更改,并在一个操作中创建提交。

参数 类型 必填 说明
repo_path string ✅ 存储库的绝对路径
message string ✅ 提交描述更改的消息

退货:提交SHA(40个字符的哈希)或“无更改可提交”

行为:

  • 自动运行 git add -A (阶段一切)
  • 使用提供的消息创建提交
  • 惰性初始化:如果repo未初始化,请先初始化它

何时使用:

  • 生成/修改代码后,保存检查点
  • 在有风险的操作之前,要有一个回滚点
  • 在开发过程中的逻辑里程碑

提交消息的最佳实践:

  • 使用常规格式: feat:, fix:, docs:, refactor:, test:
  • 描述性:“壮举:使用JWT令牌添加用户身份验证”
  • 参考更改:“修复:解析登录处理程序中的空指针”

4. list_commits

目的:检索包含详细信息的提交历史记录。

参数 类型 必填 默认 说明
repo_path string ✅ - 存储库的绝对路径
branch string ❌ "HEAD" 当前分行名称或“HEAD”
limit 整数 ❌ 50 返回的最大承诺数

退货:JSON,带有提交数组,每个提交包含:

  • sha:完整的40个字符提交哈希
  • short_sha:7-char缩写哈希
  • message:提交消息
  • author:作者姓名
  • author_email:作者电子邮件
  • timestamp:ISO时间戳

何时使用:

  • 查找用于回滚的提交SHA
  • 查看所做的更改
  • 比较两个特定的提交

5. rollback_to_commit

目的:将存储库重置为以前的提交。

参数 类型 必填 默认 说明
repo_path string ✅ - 存储库的绝对路径
commit_sha string ✅ - 目标承诺的SHA(完整或简短)
mode string ❌ "soft" 重置模式: soft, mixed,或 hard

重置模式说明:

模式 分阶段更改 工作目录 用例
soft ✅ 保存 ✅ 保留 撤消上次提交,保持更改处于暂存状态
mixed ❌ 未固定 ✅ 保留 撤消提交,保留文件但取消暂存
hard ❌ 已删除 ❌ 已删除 危险:完全放弃所有更改

退货:带有新HEAD SHA的消息

⚠️ 警告: hard 模式会永久删除未提交的更改!

何时使用:

  • 代理生成了错误代码→ 回滚到上次良好提交
  • 想以不同的方式重做工作→ 软重置
  • 实验失败→ 硬重置为干净状态

6. compare_commits

目的:显示任意两个提交之间的详细差异。

参数 类型 必填 说明
repo_path string ✅ 存储库的绝对路径
from_commit string ✅ 源代码提交SHA(旧版)
to_commit string ✅ 目标提交SHA(较新)

退货:JSON格式:

  • from_commit, to_commit:比较的SHA
  • files:已更改文件的数组,每个文件包含:
    • filename:文件路径
    • status: added, modified, deleted,或 renamed
    • additions:添加了行
    • deletions:线条已删除
    • patch:统一差异内容
  • total_additions, total_deletions:汇总计数
  • summary:人类可读摘要

何时使用:

  • 查看代理在上次迭代中更改了什么
  • 通过比较工作状态与故障状态来调试回归
  • 了解代码随时间的演变

7. create_branch

目的:为独立工作创建一个新的git分支。

参数 类型 必填 默认 说明
repo_path string ✅ - 存储库的绝对路径
branch_name string ✅ - 新分行名称
from_ref string ❌ 当前HEAD 提交/分支到分支

退货:带有分支机构名称的确认消息

何时使用:

  • 在进行实验性更改之前,创建特征分支
  • 在代理实验时保持主分支稳定
  • 并行处理多个功能

命名规范:

  • feature/add-auth -新功能
  • fix/login-bug -Bug修复
  • experiment/new-algo -实验工作

8. switch_branch

目的:切换到其他分支。

参数 类型 必填 说明
repo_path string ✅ 存储库的绝对路径
branch_name string ✅ 要切换到的分支

退货:切换后当前支路的确认

何时使用:

  • 完成功能后切换回主功能
  • 在不同工作流之间移动
  • 不同分支上的测试代码

9. list_branches

目的:显示具有当前分支指示器的所有分支。

参数 类型 必填 说明
repo_path string ✅ 存储库的绝对路径

退货:格式化列表 * 标记当前分支:

* main (abc1234): Initial commit
  feature/auth (def5678): Add login page

10. generate_commit_message

目的:根据阶段性更改自动生成提交消息。

参数 类型 必填 默认 说明
repo_path string ✅ - 存储库的绝对路径
style string ❌ "conventional" conventional 或 simple

退货:建议的提交消息和更改摘要

风格:

  • conventional:使用前缀,如 feat:, fix:, docs:
  • simple:简单的描述性信息

工作流示例

基本代理工作流

1. initialize_repo(repo_path="/project")     # Set up version control
2. [Agent generates code...]
3. commit_all_changes(message="feat: initial implementation")
4. [Agent makes more changes...]
5. commit_all_changes(message="fix: resolve edge case")
6. [Something breaks...]
7. list_commits(limit=5)                     # Find last good commit
8. rollback_to_commit(sha="abc1234")         # Restore working state

安全实验

1. create_branch(branch_name="experiment/new-algo")
2. switch_branch(branch_name="experiment/new-algo")
3. [Agent experiments with risky changes...]
4. commit_all_changes(message="experiment: try new approach")
5. [If successful]
   switch_branch(branch_name="main")
   # Merge logic here
6. [If failed]
   switch_branch(branch_name="main")        # Just abandon the branch

调试工作流程

1. list_commits(limit=10)                    # See recent history
2. compare_commits(from="abc", to="def")     # What changed?
3. [Identify the breaking commit]
4. rollback_to_commit(sha="abc", mode="soft")  # Go back, keep changes visible

依赖项

包装 版本 用途
mcp ≥1.26.0 用于服务器/工具的MCP Python SDK
gitpython ≥3.1.46 Git仓库操作
pygithub ≥2.8.1 GitHub API(未来远程操作)
pydantic ≥2.0.0 结构化数据模型

建筑

VersionControlHelperMCP/
├── pyproject.toml           # UV project configuration
├── src/version_control_helper_mcp/
│   ├── __init__.py
│   ├── server.py            # MCP server entry point
│   ├── tools.py             # Tool implementations
│   ├── git_utils.py         # GitPython wrapper
│   └── models.py            # Pydantic response models
└── README.md

错误处理

所有工具都返回明确的错误消息:

场景 错误消息
Git未初始化 “Git存储库未初始化。请先调用initialize_repo。”
提交SHA无效 “提交SHA:[SHA]无效”
未找到分支 “未找到分支'[name]'”
无需提交更改 “无需提交任何更改”

许可证

麻省理工学院