rebase 后 AI 归属不丢失git-ai 处理 rebase、squash 等 Git 历史重写的完整指南【免费下载链接】git-aiA Git extension for tracking the AI-generated code in your repos项目地址: https://gitcode.com/gh_mirrors/git/git-ai 本文要点git-ai是一个开源 Git 扩展用于追踪仓库中的 AI 生成代码每一行 AI 代码都会关联到生成它的 Agent、模型和提示词。当你执行 rebase、squash、cherry-pick 等 Git 历史重写操作后git-ai 会自动把 AI 归属数据迁移到新的提交上做到代码搬走归属跟着走不丢失、也不乱算。一、痛点历史重写为何会让 AI 归属掉线Git 的提交是用 SHA 哈希标识的。git-ai 把每行代码的归属记录谁写的人类还是某个 AI Agent存放在Git Notesrefs/notes/ai里一条 Note 对应一个提交。问题就出在这里git rebase、git commit --amend、git merge --squash、git cherry-pick等操作会生成新的提交哈希旧的提交变成死提交归属 Note 还挂在旧提交上新提交上什么都看不到归属数据就像贴错信封的信件——内容还在但地址失效了。git-ai 的 重写操作规范 对此的定义很直白任何替换提交的操作都会让 Note 悬空在死提交上因此必须有一套自动搬迁机制。二、守护机制后台守护进程如何看见你的 rebase很多工具靠 Git Hooks 感知操作但 git-ai 的设计选择是不依赖 Hooks、不包装 Git 二进制因此不会给 git 命令增加任何延迟。它的工作原理分两步监听git 会把命令执行事件写入 trace2 流git-ai 的后台守护进程读取这些事件并结合 reflog 游标精确还原哪条命令把分支从旧 tip 移到了新 tip实现见 daemon-trace2-ingestion-spec.md迁移拿到精确的旧提交 → 新提交映射后触发归属搬迁核心实现在 rewrite.rs。整个过程是异步最终一致的你照常git rebase守护进程在后台完成 Note 迁移你的 git 操作速度丝毫不受影响。三、核心算法三步把归属搬到新提交搬迁不是简单地把 Note 换个哈希git-ai 用的是基于 Git 自身数据的确定性算法git range-diff建立映射对比重写前后的提交链精确找出旧提交 X 对应新提交 Y天然支持重排、删除、拆分和 squash多对一git diff-tree计算差异对每对新旧提交的树做 diff找出哪些行原样保留、哪些行被改写行号平移 合并写入保留区域的归属行号按偏移量平移后写入新提交的 Note文件重命名也会把归属带到新路径被改写的区域则丢弃旧归属。整套机制遵循四条第一性原则详见 rewrite-ops-spec.md证据规则没有检查点证据或历史 Note 证据就不给归属——绝不靠看起来像来猜测守恒规则只要内容经 Git 自己的树 diff 确认未变归属就随之存活不可变规则所有决策输入提交 SHA、树、blob 内容在决策时必须是不可变的不读可能被用户改动的实时工作区失败关闭规则信息不足以确定新旧映射时宁可留归属空白也绝不错误归属。 一个关键取舍如果某行代码在重写中被改写了哪怕人类觉得是同一行旧归属会丢弃。模糊匹配属于启发式猜测被规范明确禁止——宁可暴露空白也不制造假归属。四、支持哪些 Git 重写操作git-ai 对常见重写操作的覆盖情况如下操作归属是否保留说明git rebase含git pull --rebase✅range-diff 精确映射后迁移git commit --amend✅按 1→1 非快进处理git cherry-pick✅用 patch-id 配对源提交git merge --squash✅多个源 Note 合并进一个新提交git reset --soft / --mixed✅重建未提交归属的工作日志git stash/stash pop✅工作日志随 stash 迁移与还原git merge合并提交✅两侧归属分别保留git mv重命名文件❌暂未跟踪重命名git filter-branch/filter-repo❌不跟踪批量历史重写对于 GitHub、GitLab 平台侧的Squash and Merge / Rebase and Merge发生在服务器端git-ai 提供了 CI Actions 方案github.yaml、gitlab.yaml保证合并后归属依然可查。五、rebase 遇到冲突归属怎么算这是最容易翻车的场景git-ai 的规则清晰可预期保留下来的行谁的内容存活就保留谁一方的归属解决冲突时新写的行只有当该写入有 AI 检查点或已知人类检查点证据时才标注为对应归属没有任何证据的改写区域留空未归属——即使冲突前的旧 Note 里那段代码曾是 AI 写的。这是刻意为之的收紧内容变了就需要新证据把旧归属按位置贴回改写后的行属于错误归属。六、如何验证归属没有丢git-ai 用测试为这套机制兜底每个操作家族都有确定性集成测试rewrite_ops_attribution.rs、rebase.rs、squash_merge.rs、stash_attribution.rs 等每一次冲突解决模式保留 ours/theirs/双方、AI 重写、人类重写、双方删除都有断言三类归属的回归测试还有一个归属模糊测试器fuzzer对操作组合施加压力每个发现的问题都会最小化为确定性回归用例规格见 attribution-fuzzer-spec.md。日常使用中的自检也很简单# 查看某个提交上的 AI 归属 git ai show commit # 看每一行代码是 AI 还是人写的 git ai blame file # 统计一段时间的 AI 代码占比 git ai stats --json七、小结git-ai 把 AI 归属存在Git Notes中重写历史后由守护进程自动迁移不依赖 Hooks、零延迟核心是range-diff精确映射 diff-tree保留区域平移辅以失败关闭原则保证不错误归属rebase、amend、cherry-pick、squash、stash、reset 等主流操作均已覆盖平台端 Squash and Merge 可用 CI Actions 补齐想深入了解设计细节推荐阅读 rewrite-ops-spec.md 与 daemon-trace2-ingestion-spec.md。让 AI 写的代码始终名正言顺历史再怎么重写都不怕。【免费下载链接】git-aiA Git extension for tracking the AI-generated code in your repos项目地址: https://gitcode.com/gh_mirrors/git/git-ai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考