AI 改变代码提交习惯：开发者不再发布 Git 提交记录

AI 改变代码提交习惯：开发者不再发布 Git 提交记录

最近，一位开发者在发布新版本时做了一个不寻常的决定：他没有像往常一样在原有仓库上堆叠提交，而是将整个项目作为一个单独的提交推入一个全新的空仓库，并附上签名标签，由 CI 从该标签构建二进制文件。这个项目名为 contenox 1.0.0，其背后的 957 个提交仍然保留在旧仓库中作为历史，但不再作为项目的发布方式。

这一做法引发了一个问题：在 AI 辅助编程日益普及的今天，Git 提交记录的意义是否正在改变？

提交记录曾经意味着什么

GitHub 的工作流程建立在四个古老的假设之上，这些假设如今已很少被明确提及。作者在文章中列举了这些假设，但并未详细展开。不过，从上下文可以推断，这些假设与提交的粒度、可读性、可追溯性以及协作方式有关。传统上，提交记录是项目演进的日志，是开发者之间协作的媒介，也是代码审查的基础。

然而，当 AI 开始参与代码生成时，这些假设开始动摇。AI 可以快速生成大量代码，使得提交变得频繁且杂乱，或者反过来，AI 生成的代码块太大，难以拆分出有意义的提交。提交记录逐渐失去了其作为人类可读的变更日志的价值。

为什么选择不再发布提交

作者在发布 contenox 1.0.0 时，选择将整个项目作为一个提交发布，而不是保留原有的提交历史。这一决定并非出于懒惰，而是因为提交记录已经无法准确反映项目的开发过程。AI 生成的代码使得提交信息变得模糊，甚至可能误导读者。与其维护一份不真实的提交历史，不如直接发布最终版本，让用户专注于代码本身。

这种做法也改变了 Git 的角色：从协作工具转变为发布工具。提交记录不再是开发过程的记录，而是版本发布的标记。作者强调，旧仓库中的 957 个提交仍然公开，作为历史存在，但新仓库的单一提交才是项目的正式发布形态。

开发者如何适应这一变化

这一现象并非个例。随着 AI 编程工具的普及，越来越多的开发者可能面临类似的困境：如何管理由 AI 生成的代码，以及如何维护有意义的提交记录。一些团队可能选择让 AI 自动生成提交信息，但这样做的结果往往是提交信息变得冗长且缺乏重点。另一些团队则可能像作者一样，放弃细粒度的提交，转而采用更粗粒度的发布策略。

对于开发者个人而言，适应这一变化意味着重新思考 Git 的使用方式。提交记录不再需要事无巨细地记录每一步，而是可以聚焦于重要的里程碑。同时，代码审查的流程也可能需要调整，因为 AI 生成的代码往往难以逐行审查，而更需要在整体层面进行验证。

Git 在 AI 时代的新角色

Git 本身并不会消失，但它的角色正在演变。在 AI 时代，Git 可能更多地被用作发布和版本管理的工具，而不是开发过程的实时记录。开发者可以保留完整的开发历史，但选择性地发布那些有意义的提交，或者像作者一样，直接发布最终版本。

这种变化也带来了新的挑战。例如，如何确保发布的可重复性？作者通过 CI 从标签构建二进制文件，保证了发布的可信度。此外，如何平衡透明度和简洁性？保留旧仓库作为历史，既满足了透明度的需求，又避免了新仓库的混乱。

总之，AI 正在改变开发者的工作方式，Git 提交记录的消亡或许只是其中的一个缩影。开发者需要找到新的方法来记录和分享他们的工作，而 Git 本身也将适应这一变化，继续在软件开发的生态系统中扮演重要角色。

参考来源