Git 提交记录里突然冒出一个我从未见过的作者名字那个改动的确不是人干的。上个月我把一个 AI 编程助手接进了团队的小工具仓库它干活确实利索一口气改了十几个文件推代码也毫不含糊。但到了晚上做代码审查的时候git log里的提交者让我愣了几秒——它借用的是我的私人邮箱可那活儿真不是我干的。那一刻我意识到一个很现实的问题当 AI 开始真正参与编码、提交、推送Git 这个原本只属于“人”的协作空间必须给它一个合法且可追溯的身份。这不只是仪式感而是审计、回滚、分工和事故追责的地基。这次折腾下来我最大的感受是给 AI 在 Git 里“上户口”这件事看起来只是两行git config实际上牵扯到 SSH 密钥、提交规范、钩子脚本、分支策略乃至团队意识。我踩了不少坑也沉淀出了一套可以直接抄走的方案。今天把这整个过程的思路、步骤和教训完整记录下来给同样在用 AI agent 写代码、又不想让 Git 历史变成一团糊涂账的朋友参考。1. 为什么我要把 AI 写成 Git 里的“一个人”1.1 从一次提交记录引发的“查案”最早我们团队用 AI 写代码方式很原始AI 给出 diff人工粘贴到编辑器再用人的身份提交。一开始没什么问题因为最终落地动作还是人做的。可后来 AI agent 工具越来越成熟它自己能读仓库、改文件、跑测试、git add、git commit、git push一条龙全自动。这时候问题就来了——它默认继承运行环境里的 Git 身份也就是我配置在~/.gitconfig里的user.name和user.email。于是我的提交记录里出现了大量“经我之手”但并不是我写的代码。白天还好做周报和事故复盘时就尴尬了某个紧急修复到底是谁做的为什么 commit message 写得像论文摘要一样规整如果三个月后这段代码出了问题我应该找谁问上下文答案只能是“问机器人”可机器人的对话上下文早就不在了。1.2 author、committer、co-author三个身份角色要拆开看在给 AI 安排身份之前得先把 Git 提交信息里的几个字段弄明白。很多人对git log的理解停留在“谁提交的”这一层实际上一个提交对象里至少藏着三个不同的身份线索身份字段含义典型出现场景author这段代码改动的原始作者AI 生成补丁并提交你替同事提交时作者仍是同事committer把改动正式写入仓库的人你执行git commit的那一刻committer 就是你co-author共同作者写在提交信息尾部的 trailer通过Co-Authored-By: Name email标注协作贡献我建议的落法很简单谁产生了这段代码author 就给谁谁执行了提交动作committer 就是谁的人在 AI 产出基础上做了修改或 review用 co-author 补上人的贡献。这样每个提交都能回答两个问题这代码是谁写的这提交是谁放的AI 成为 Git 里的“一个人”本质上是让 author 字段可以指向一个机器身份而不是继续盗用人类的姓名。1.3 可追溯性比“署名仪式感”更重要给 AI 上户口最直接的好处是能用命令一键过滤它的贡献。比如我想看这个 AI agent 这周在这仓库里动了什么可以执行git log --authorai-assistant --since1 week ago --oneline代码审查的时候我只想知道“哪些提交是 AI 干的、有没有经过人确认”一条git log --author就拎得清清楚楚。出问题要回滚的时候也能按 author 缩小排查范围。相比之下如果 AI 所有提交都顶着我的名字过滤、统计、追责都会变成一场灾难。可追溯性不是给机器看的是给未来的自己和队友看的。注意给 AI 设身份不是让它“假装是人”而是给它一个可以被人识别的、稳定的、独立的标识。很多人误会这一点以为要把 agent 伪装成某个真实用户恰恰相反——越像“机器人”越好管理。2. 建立 AI 身份的第一步仓库级配置与一整套 Git 环境2.1 创建独立的 AI bot 身份而不是复用我的个人身份身份设计上我推荐一个仓库或一组协作仓库里只给 AI 一个专属身份。这里有个关键点一定不要用全局配置只在仓库本地配置。全局配置会对这台机器上的所有 Git 仓库生效如果 AI agent 同时帮你处理个人项目和工作项目身份就串了。正确做法是在目标仓库里执行仓库级配置cd /path/to/your-repo git config user.name ai-coding-bot git config user.email ai-coding-botexample.com这样即使这台机器上人类用户的全局身份是zhangsan zhangsanexample.comAI agent 在这个仓库里提交时也只会使用仓库级配置的 bot 身份。两者不打架。如果你关心邮箱隐私或者公司要求邮箱必须符合域名规范可以在example.com上建一个类似ai-coding-botexample.com的专用邮箱不一定要真的能收信只要在 Git 里保持一致即可。2.2 SSH 密钥、Gitee 公钥与推送权限的落地身份配置好之后AI agent 要能顺利推送代码还需要一把它能用的 SSH 密钥。这里我不建议直接复制你自己常用的~/.ssh/id_ed25519而是给 AI 单独生成一把专用密钥原因很简单你之后如果轮换个人密钥不会影响机器人的推送链路反过来机器人密钥如果泄露撤销它也不会误伤你的其他仓库。生成密钥并添加到 Gitee 的过程大致如下# 为 AI agent 生成独立密钥 ssh-keygen -t ed25519 -C ai-coding-botexample.com -f ~/.ssh/id_ed25519_ai_bot然后查看公钥内容并复制cat ~/.ssh/id_ed25519_ai_bot.pub登录 Gitee进入“设置 - SSH 公钥”把公钥粘贴进去。为了便于区分标题可以写成ai-coding-bot-work-repo。之后为了让git push使用这把密钥而不是默认密钥最好在~/.ssh/config里加一段通配Host gitee.com HostName gitee.com User git IdentityFile ~/.ssh/id_ed25519_ai_bot IdentitiesOnly yes验证连通性ssh -T gitgitee.com如果返回类似Hi ai-coding-bot! Youve successfully authenticated这样的信息说明 AI 的推送通道已经通了。GitHub 的流程也一样只是结束点是“Settings - SSH and GPG keys”。2.3 顺手把分支策略和默认行为固定下来给 AI 上户口的同时我建议把一些环境默认值一起固定好避免 agent 在一台新机器上自由发挥。比如很多 AI 编程工具初次运行时会把默认分支名搞成五花八门或者提交时换行符处理得乱七八糟。我在这类准备环节通常会检查三条配置git config --global init.defaultBranch main git config --global core.autocrlf input git config --global core.quotepath falseinit.defaultBranch main保证新建仓库的默认分支是main避免出现master和main混合的尴尬。core.autocrlf input在类 Unix 系统上避免换行符被无故改掉Windows 上则要根据团队成员的习惯灵活调整。core.quotepath false则是让中文文件名在git status里可读不至于变成一串转义码。这些看起来零碎但对机器人自动化流程来说环境越稳定它跑得越省心。如果你们对数据合规要求高也可以把 AI agent 接到本地私有化部署的大模型上身份照样用这套方案因为身份和模型跑在哪无关只和 Git 提交记录相关。本地部署的好处是上下文和代码片段不出内网配合 bot 身份整个链路在审计上更干净。3. 控制 AI 的每次提交信息提示词、钩子和 amend 修正3.1 给 AI 写好“提交信息”的提示词模板身份只是第一步更关键的是 AI 每次提交时写什么 commit message。如果不做约束有些 agent 会写“update code”“fix bug”这种毫无信息量的话有些又会写出几百字的小作文把重构背景、上下文、心理活动全塞进去。这两种都不是团队想要的提交风格。我给 AI agent 的提示词里固定了一段提交规范直接放在系统提示词里当你执行 git commit 时请使用 Conventional Commits 规范 - 标题不超过 72 个字符格式为 type(scope): description - type 只用 feat, fix, refactor, docs, chore, test 六种 - 正文用短横线列表说明“改了什么”和“为什么改” - 不要写“AI 生成”“自动化修改”这类无信息量的措辞 - 在提交信息末尾追加 Co-Authored-By: ai-coding-bot ai-coding-botexample.com你会发现让 AI 规范提交有个额外好处它的 commit message 往往比人工写的更一致因为大模型擅长从 diff 中归纳改动意图。只要模板定得清楚产出基本是合格的。3.2 prepare-commit-msg 钩子强制添加 AI 署名提示词是“软约束”模型有时候会忘钩子脚本是“硬约束”忘了我也会帮你补上。我最常用的是prepare-commit-msg钩子。它的工作时机是在提交信息编辑器打开之前可以修改将要生成的提交信息。在.git/hooks/prepare-commit-msg里放这样一个脚本#!/bin/bash # 用于给 AI agent 的提交自动补上署名 COMMIT_MSG_FILE$1 COMMIT_SOURCE$2 # 如果是 amend 或 merge 等场景不重复追加 if [ $COMMIT_SOURCE message ] || [ $COMMIT_SOURCE template ]; then exit 0 fi # 已经带署名就不再追加 if ! grep -q Co-Authored-By: $COMMIT_MSG_FILE; then printf \n\nCo-Authored-By: ai-coding-bot ai-coding-botexample.com\n $COMMIT_MSG_FILE fi如果你只想让这个钩子对 AI agent 生效、人类提交不加署名可以在 agent 的执行环境里设置一个环境变量比如AI_AGENT1然后钩子里加一个判断if [ $AI_AGENT 1 ] ! grep -q Co-Authored-By: $COMMIT_MSG_FILE; then printf \n\nCo-Authored-By: ai-coding-bot ai-coding-botexample.com\n $COMMIT_MSG_FILE fi钩子脚本写好后记得给执行权限chmod x .git/hooks/prepare-commit-msg之后 AI agent 每次提交就算提示词忘了补署名钩子也会自动兜底。这个组合是我目前用下来最稳的提示词管“写得好不好”钩子管“署名在不在”。3.3 当提交需要修改时git commit --amend 的正确姿势AI 提交完之后如果人审出问题最常用的修正工具就是git commit --amend。这个命令我在热搜词里也看到很多人搜确实值得单独讲清楚。它本质上是“把上一次提交重做一遍”能改提交信息、能补文件、能换作者。最常见的三种用法# 1. 只改提交信息不改变文件内容 git commit --amend -m feat: 完成登录模块的重构 -m 详情见正文 # 2. 把暂存区的改动并入上一次提交但保留原提交信息 git add src/auth/login.js git commit --amend --no-edit # 3. 修正提交的作者身份 git commit --amend --authorai-coding-bot ai-coding-botexample.com --no-edit比如AI 忘了以 bot 身份提交导致提交记录显示的是你的邮箱就可以用第三条命令把 author 修正回来。但我必须强调一个使用场景限制只 amend 还没推送到远端的提交。如果提交已经git push出去了amend 会导致本地和远端历史分叉除非force push而 force push 可能覆盖队友的提交风险非常大。我在团队里定了一条铁律远端分支上的提交一律不许 amend要改就开新的修复提交。如果确实需要清理历史也必须有专人确认后再操作绝对不交给 AI agent 自做主张。提示很多 AI agent 工具内置了“自动修复上次提交”的能力底层就是执行 amend。如果你不想让它在不知不觉中重写历史务必在 agent 配置里关掉自动 force push或者设置成每次 force push 都要人工确认。4. AI 进入仓库后我们踩过的四个真实坑4.1 fatal: not a git repository——agent 经常在错误的“当前目录”里操作这是 AI agent 刚接入仓库时最常报的错报错原文是fatal: not a git repository (or any of the parent directories): .git。我们最开始以为是没有安装 Git后来发现是 agent 的工作目录根本不在仓库里。它可能在某个临时目录、缓存目录或者容器挂载的路径里执行了git status而那个路径的上层目录其实没有.git目录。排查链路值得记录一下先确认当前目录里有没有.git文件或目录。用ls -a看如果.git存在再看是不是损坏了。用git rev-parse --show-toplevel它能输出仓库根目录如果返回的是空或者报错再确认环境变量GIT_DIR是否被 agent 设置成了奇怪的路径。执行env | grep GIT检查最后如果 agent 跑在容器或沙箱里确认它启动时是否把宿主的仓库目录挂载进去以及挂载点是否包含.git。这个坑的根源在于 AI agent 的“目录感”不好。它可能记得文件路径但不会主动关心当前进程的工作目录在哪。解决方案不是反复纠正它而是给它的工作指令里固定加上一行所有 Git 命令必须在仓库根目录下执行执行前先运行pwd确认当前路径。4.2 merge 冲突时AI 不该自作主张第二次比较严重的坑出现在分支合并。AI agent 处理冲突时如果配置得不严格它可能会自作主张选择一侧的修改。对大模型来说两个版本看起来可能都“合理”但它缺少业务上下文很多时候选错的那一侧恰恰是生产环境有依赖的关键逻辑。我们遇到过最惊险的一次合并分支时AI 自动采用了“ours”策略把新分支上调整过的接口签名覆盖回了旧版本导致测试阶段才发现参数对不上又花了大半天回滚。从那以后我在给 AI agent 的约束里增加了这么一段当 git merge 或 git rebase 发生冲突时 1. 禁止自动选择任意一侧的内容 2. 停止操作并输出冲突文件清单 3. 列出冲突两侧的关键差异 4. 等待人工给出解决方案。同时在发起合并的时候我建议使用--no-commit参数让合并停下来等待人工审阅git merge feature-ai-refactor --no-commit这样即使 agent 顺利完成了合并也不会直接生成一个“既成事实”的提交而是给人留一个检查和干预的窗口。4.3 那些不该被提交的文件为什么会冒出来AI agent 提交了一堆无关文件这是第三个高频问题。之前我们的.gitignore已经覆盖了node_modules和dist但 agent 在生成代码时还是在某个目录里创建了一个.env文件并直接git add .进去了。幸好仓库是私有仓库没有造成实际泄露但这件事给我提了个醒。我现在的做法是两件事同时做在 agent 的系统提示词里黑名单化禁止提交任何包含密钥、口令、连接串的文件遇到疑似敏感内容必须停下询问。每次提交前用git diff --cached --stat让 agent 自检暂存区里有哪些文件把非代码文件剔除。如果发现已经误提交了敏感文件立刻执行git rm --cached .env echo .env .gitignore git commit -m chore: remove env file from tracking注意git rm --cached只能让文件不再被跟踪历史提交里仍然残留着该文件内容。如果仓库已经公开或者包含真正的生产密钥那就要考虑用git filter-repo重写历史并做全量通知和密钥轮换。不过重写历史这件事风险不小尤其是多人在协作的分支上必须谨慎评估。4.4 全局配置“串号”导致的提交归属混乱最后一个坑其实来自我们自己不是 AI 的锅。当时为了让 agent 在所有仓库里都能独立提交我在某台测试机上执行了git config --global user.name ai-coding-bot。结果测试机上的其他真人用户也在这台机器上提交代码他们的提交全部被冠以 bot 之名。那段时间的 Git 历史里机器人的“产量”高得离谱人工的提交反倒被淹没了。排查方法是用这个命令git config --list --show-origin它会显示每一行配置来自哪个文件、哪个层级。看到file:/home/user/.gitconfig user.nameai-coding-bot就说明全局配置把真人的身份污染了。处理方法是清掉全局里的 bot 身份只回仓库级配置git config --global --unset user.name git config --global --unset user.email从此我们立了个规矩AI 的身份一律只写在仓库级 config 里不允许出现在全局 config 中。这台机器如果还要给多个仓库服务要么每个仓库单独配置要么用includeIf按目录条件加载不同的身份配置。后者适合场景更复杂的团队篇幅关系这里不展开。5. 一周实战后的复盘AI 参与 Git 工作流的最佳姿势5.1 三种适合团队直接抄的人机协作模式身份、钩子、规范都落地之后我们花了一周时间跑了几种不同的协作方式最后总结出三种可行模式分别适合不同规模的团队。模式适用场景基本流程关键控制点本地助理模式个人项目、小团队AI 在本地修改代码并提交人做 code review 后推送AI commit 时带 bot 身份人不修改 AI 的 authorMR 机器人模式中大型团队AI 在独立分支提交推送到远端后开 MR/PR人 review 后合入分支策略强制保护禁止直接 push main定时维护模式依赖升级、文档更新AI 按计划任务创建分支、提交、合入合入动作必须走流水线测试全绿才允许合并三种模式不是互斥的完全可以同时存在。比如主仓库走 MR 机器人模式个人实验仓库用本地助理模式而每周的依赖更新交给定时维护模式。关键是每种模式都有明确的“最终负责人”AI 可以当执行者但不能当决策者。5.2 哪些提交应归给 AI哪些必须归给人在维护 Git 历史的过程中我渐渐形成了一条归属判断规则凡是 AI 直接生成的代码且 AI 自己执行的提交author 归于 AI 身份凡是人改过之后再提交的author 归人同时在正文里用Co-Authored-By标注 AI 的贡献凡是 AI 提交但人做实质性改写后合入author 归人AI 作为 co-author 保留。这个规则的好处是统计“AI 产出了多少代码”时直接按 author 或 co-author 过滤就行统计“哪个工程师负责了一块逻辑”时也可以不被 AI 的提交淹没。Git 的提交记录不应该撒谎但也要能精确回答“这段逻辑的当前责任人是谁”。5.3 可以直接抄走的 AIGit 配置清单复盘完整套流程我把配置文件整理成了清单。如果你手头正好有 AI 编程 agent 要接进 Git 仓库照着设置基本能少踩 80% 的坑。# 1. 仓库级 AI 身份 git config user.name ai-coding-bot git config user.email ai-coding-botexample.com # 2. 全局限定默认行为 git config --global init.defaultBranch main git config --global core.autocrlf input git config --global core.quotepath false # 3. 为 agent 生成专属 SSH 密钥 ssh-keygen -t ed25519 -C ai-coding-botexample.com -f ~/.ssh/id_ed25519_ai_bot生成的公钥内容放到 Gitee / GitHub 的 SSH Keys 里。然后在.git/hooks/prepare-commit-msg里放上前面写的钩子脚本赋予执行权限。最后在 agent 的系统提示词里放上两段话一段规定 commit message 格式一段规定冲突处理原则。整个基建就齐了。最后说一点个人体会。给 AI 在 Git 里上户口这件事技术难度其实不高真正的难点是你愿意在“团队规范”层面花多少心思。我见过很多团队用了 AI agent 提效却在提交记录上留下一笔糊涂账短暂提速换来长期混乱。如果你现在刚开始让 AI 碰代码强烈建议从一开始就给它独立身份、固定提交规范、留好审查环节。等到 AI 已经在一堆提交记录里留下混乱痕迹之后再来补救成本会高很多。我自己现在的习惯是每新建一个跟 AI 协作的仓库先花五分钟把这份配置跑一遍之后再让 agent 放手干后面基本不用操心 Git 历史的问题。