Git 2.29.0版本 于 2020年10月发布，其中包含了两个阿里巴巴贡献的新特性。阿里巴巴贡献的新特性让 Git 牵手 Gerrit，让 GitHub 模式的代码平台可以像 Gerrit 一样工作。
阿里巴巴在给 Git 社区贡献的第一个版本中，只在服务端引入新的钩子，并未修改客户端相关代码。为了能让社区接受修改，我们的技术贡献者，阿里云云效资深技术专家知忧以实现 Gerrit 的类似功能作为卖点向社区进行"推销"。Junio（Git 维护者，Google）第一时间承认这个贡献的价值：
And I think it is reasonable to add a new hook that takes over the whole flow in "git receive-pack" to do so.
同时指出疑问：向 Gerrit 推送一个引用A (refs/for/master)，Gerrit 创建了另外的引用B (refs/changes/1/123)，那么 Gerrit 是如何告诉客户端正确地更新本地跟踪分支的？
How do Gerrit folks deal with the "we pushed to the server, so let's pretend to have turned around and fetched from the same server immediately after doing so" client-side hack, by the way?
只有屈指可数的人才能像 Junio 这样发出灵魂的拷问！于是在后续的代码评审中，也与 Junio 以及 GitHub 的 Jeff King (Peff) 之间进行了多次交流，代码迭代了19个版本，为 Git 服务端和客户端新增了一个能力：report-status-v2。
云效 Codeup 是业界第一个支持 git 2.29 新功能的代码平台
阿里云云效Codeup是业界首个支持 Git 2.29 新功能的代码平台。当用户执行 git push 命令时，特殊的目标分支会触发服务端 proc-receive 钩子，完成特定功能。
命令行创建代码评审
在云效Codeup 的"新建合并请求"按钮的下方，有一条低调的提示，如图：
参照提示信息的说明，用户会看到用标准的 Git 命令行就可以直接在仓库中创建代码评审。例如用户执行下面命令将当前（HEAD）的更改推送到服务端，向服务端的 master 分支创建代码评审：
git push origin HEAD:refs/for/master/local/branch
另外，GitHub 引入 Git 2.29 新功能没有那么快，原因是 GitHub 的架构是分布式三副本架构，使用的是定制版本的 Git，不能通过升级到 2.29 来支持 proc-receive 钩子，需要另行开发。未来已来，全新的 Git 体验，访问云效Codeup。
