——三类代码协同模式，Git大神告诉你到底如何选
1. Git代码协同模式基础
为团队规划研发协同模式之前，有必要了解Git的几种协同模型。
其中多种协同模型中使用了代码评审。代码评审在不同的代码平台有不同的称谓。
∙ GitHub应该是受到了 git 命令 git request-pull的启发，将代码评审称为拉取请求（pull request, PR）。
∙ GitLab因为代码评审最终被合并（也支持变基 rebase）到目的分支，因而称其为合并请求（merge request, MR）。
∙ 阿里云·云效的代码平台，代码评审不但用于分支提交变更的评审，也将支持分支创建、分支删除、强制推送行为的评审，因此云效代码平台将代码评审称为变更请求（change request），简记为 CR。
1）GitHub-Flow：开源社区标配的协同模型
GitHub 在2008年一经推出，就凭借其创造性的“仓库派生 + pull request”的工作流征服了开源社区。这是因为这一协同模式解决了开源社区最大的痛点：仅对少数人开放代码仓库写权限和人人皆可贡献开源的矛盾。
a）GitHub 工作流的使用
对于开源项目的参与者，可以划分为两类角色：维护者和贡献者。
∙ 维护者：具有代码仓库最高权限，可以创建分支、删除分支、更新分支，以及向分支强制推送。
∙ 贡献者：没有仓库的写权限，只拥有读权限，不能向代码仓库直接推送。
GitHub 创造了“仓库派生”这一机制，解决了代码仓库的只读用户向代码仓库贡献的途径。我们以 k8s 社区为例，介绍 GitHub 工作流。
（图示摘自 https://www.kubernetes.dev/docs/guide/github-workflow/）
GitHub 工作流说明：
∙ 创建派生仓库。说明：作为 k8s 项目的贡献者，没有 k8s 仓库的写权限，但可以通过 GitHub 的 fork 功能将 k8s 项目（kubernetes/kubernetes）派生到自己名下，如仓库$user/kubernetes。用户对于自己的派生仓库拥有写权限。
∙ 将自己的派生仓库克隆到本地。执行命令：
◦ git clone https://github.com/$user/kubernetes.git
∙ 本地仓库和上游仓库分支（如master分支）同步。说明：派生仓库并不能和上游仓库自动同步，为避免本地提交和上游仓库出现过大的偏离导致合并冲突，在每一个功能开发前，以本地仓库为中介，将远程上游仓库的新提交同步到远程的派生仓库中。
◦ git remote add upstream https://github.com/kubernetes/kubernetes.git
◦ git fetch upstream
◦ git switch master
◦ git rebase upstream/master
◦ git push origin master
∙ 创建一个本地分支（如 mybranch分支）。说明：为每一个开发任务创建一个单独的本地分支是一个好习惯，这样可以在一个本地仓库中，用不同的本地分支关联不同的 pull request。
◦ git switch -c mybranch master
∙ 在本地分支中开发。
◦ git add <file>
◦ git commit -s
∙ 将本地分支推送到远程派生仓库。
◦ git push -u -f upstream HEAD
∙ 创建代码评审（pull request）。即：通过 GitHub 的 Web 界面，从远程派生仓库向远程上游仓库创建 pull request。
∙ 本地仓库中新的改动（提交）再次推送到远程的派生仓库，会自动刷新代码评审中的提交。
b）优势和缺点
GitHub-Flow的优势：
∙ 满足了开源项目人人皆可贡献的目标。在2008年，仓库派生是基于原生 Git 实现开源协同的最易用的方案。
∙ 易于管理。将代码管理工作化整为零，每个派生仓库由派生者自行管理，开源项目的负责人无需进行复杂的授权管理和分支管理。
∙ 派生仓库是一个独立的拷贝，不会受到上游变更（许可证变更、开放性变更、授权变更等）的影响。
GitHub-Flow的缺点：
∙ 仓库同步操作复杂。同步操作涉及到远程上游仓库、远程派生仓库、本地克隆仓库的三方数据同步，开发者要熟悉 git remote、git rebase等命令。
∙ 派生熔断导致仓库授权失去管控。在仓库的开放性发生变更（例如从公开项目转换为私有项目），主项目和派生项目之间的派生关系被切断，成为没有派生关系的不同的项目，派生项目的管理权也从主项目自动交接给派生项目的用户。
∙ 不适合于多仓库类型的项目（如 Android 项目）。由于多仓库的存在，放大了派生仓库和上游仓库同步的复杂度。
∙ 派生仓库导致服务端存储出现冗余。
上述缺点，尤其是派生熔断导致仓库授权失去管控，无法被企业管理者所接受。因此，GitHub 工作流只适合于外部开源或者企业内部开源项目，而不适合企业私有项目。
2）分支评审：仅适用于私有仓库的协同模型
GitHub 的派生工作流会因为仓库可见性从公开变为私有导致派生熔断，造成仓库授权失去管控，因此派生仓库协同模式通常不被企业所接受。进而，被所有代码平台所支持的分支评审模式自然成为企业私有仓库协同的最直观的选择。
a）分支评审模式的使用
企业私有代码仓库的协同者通常包含三类角色：管理员、开发者、贡献者。
∙ 管理员：即仓库的维护者，具有代码仓库最高权限，可以创建分支、删除分支、更新分支，以及向分支强制推送。
∙ 开发者：具有仓库的读写权限，除了不具备删除仓库等危险操作的权限之外，和管理员一样，具有创建分支、删除分支、更新分支，以及向分支强制推送的权限。
∙ 贡献者：没有仓库的写权限，只拥有读权限。
上述三个角色中，只有开发者和管理者拥有写权限，因此只有这两种角色才能够使用分支评审模式参与代码仓库的协同。
采用分支评审模式协同，开发者在服务端仓库中创建临时分支，将本地提交推送到相应的临时分支上，再从该临时分支创建到目标分支的代码评审。临时分支通常在代码合入后清除。用户在服务端创建的临时分支，根据目标分支的不同，有着不同的名称。如：
∙ 特性分支（topic branch）：为完成某一功能开发而创建的临时分支，通常基于主干分支创建。不同的项目对于特性分支可能有不同的命名规范，例如：topic/<name>、feature/<name>。
∙ 热修复分支（hotfix branch）：为修复已发布的历史版本的缺陷，基于历史发布版本（如 v1.0 版本）创建的分支。不同的项目对于热修复分支可能有不同的命名规范，例如：hotfix/<name>。
下面的示意图演示了一个开发者如何通过分支模式将特性分支（如 topic/1）合入到主干分支（如 master）。
说明如下：
∙ git clon开发者将远程仓库克隆到本地：
◦ e https://example.com/group/repo.git
∙ 本地创建分支，如 topic/1分支：
◦ git switch -c topic/1
∙ 在本地分支中开发。
◦ git add <file>
◦ git commit -s
∙ 将本地topic/1分支推送到远程服务器上。
◦ git push -u origin HEAD
∙ 开发者访问 Web 界面，选择从 topic/1分支向 master分支创建代码评审（如编号 123 的代码评审CR #123）。
∙ 本地仓库继续修改，创建或更新提交。
◦ git add <file>
◦ git commit -s
∙ 执行推送命令，自动刷新远程仓库中的代码评审（CR #123）。
◦ git push
∙ 代码评审通过，从Web 界面访问 CR#123，点击合入完成分支 topic/1到分支 master的合入。
∙ 分支 topic/1合入后，可以手工删除该分支。
b）GitLab 的保护分支功能
保护分支功能最早由GitLab 实现，目的是确保分支能够严格采用分支评审模式进行协同。
∙ 通过输入名称通配符，确保与之匹配的分支被加以保护。
∙ 可以设置被保护的分支必须使用代码评审才能够合入，不能直接推送。
∙ 可以设置被保护的分支不能够被强制推送，管理员也不例外。
保护分支由管理员进行设置，通常仅对代码仓库的主干分支、维护分支进行保护，而不对特性分支进行保护。
c）优势和缺点
分支评审模式的优点：
∙ 如果某个特性的开发周期比较长，创建一个长期存在的特性分支，便于开发者能够随时执行推送命令将本地提交推送到服务端，避免本地误操作而丢失数据。
∙ 如果某个特性由多人协同开发，设置一个特性分支，便于多个用户进行工作协同。
分支评审模式的缺点：
∙ 如果开发者无论是否必须、无论特性的大小，都采用分支评审模式，且不能及时删除过时的特性分支，就会在服务端遗留大量过时的分支。仓库中过多的特性分支和仓库的核心分支（主干、维护分支）混杂，会给开发者带来困惑，也会导致用户操作过程的性能下降。
∙ 缺乏有效的分支授权管控，无法限制对于非保护分支的推送、创建、删除权限的管控，可能导致特性分支被误删，或者特性分支因多人协同时强制推送被覆盖，造成代码丢失、协同效率的下降。
d）分支评审模式的改进
采用AGit-Flow 协同模式，直接通过命令行创建代码评审，而不在仓库中创建临时分支，可以解决了分支评审模式中特性分支过多、混乱的问题。
至于分支评审模式缺乏对特性分支创建、删除、强制更新的授权，阿里云·云效代码平台提供推送评审模式，实现自助式分支管理，以解决代码仓库中分支管理无序的难题。
3）AGit-Flow：兼顾开源和私有项目的集中式协同模型
阿里巴巴内部的代码平台在2019年实现了一种集中式工作流——不需要仓库派生，就可以让只读用户贡献代码。这种集中式工作流既适合于开源项目，又适合于私有项目。因其核心实现基于阿里云代码团队定制版的Git（AGit），因此将此工作流命名为AGit Flow。
AGit Flow在设计上参考了 Gerrit，使用体验和 Gerrit 类似。在2020年，阿里巴巴将这一成果核心代码贡献到Git社区，对Git服务端和Git客户端能力进行了扩展。参见：《Git2.29让Git成功“牵手”Gerrit》。
在2023年6月，由阿里云代码团队参与建设的AtomGit开源平台上线，标志着首次将 AGit 工作流带入到了开源社区（atomgit.com）。
a）AGit 工作流的使用
AGit 工作流在设计上参考了 Gerrit。
Gerrit 是谷歌开发的代码平台，被Android、OpenStack 等项目拿来管理各自的研发协同。Gerrit 的仓库格式也是 Git，但是服务端实现采用了 Java 开发的Git兼容工具jGit 而非原生 Git，除了带有谷歌风格的逐提交代码评审之外，还实现了无需派生仓库、所有贡献者基于同一个上游仓库进行协同的集中式工作流。
Gerrit 这一集中式工作流既适合开源项目，也适合私有项目。但是因为 jGit 在性能和功能上落后于原生 Git，且 Gerrit 的使用体验、可扩展性存在的问题，导致 Gerrit 协同模式没有 GitHub 工作流那样的被人熟知和使用广泛。
在2020年，阿里巴巴向 Git 社区贡献两个功能扩展，一个成为Git服务端的功能扩展（proc-receive 挂钩），一个成为Git客户端功能扩展（report-status-v2 能力）。这样代码平台的设计者可以在服务端针对用户的 git 推送行为进行相应的扩展，体验上类似Gerrit，但是能力更加强大。即：
∙ 用户向仓库的特殊引用（如refs/for/master）推送，生成代码评审。其中特殊引用refs/for/master在服务端并不存在，也不会因为用户的推送操作而被创建，用户的推送操作被服务端扩展程序接管，创建代码评审。
∙ 客户端收到服务端操作的真实结果，并向用户报告。例如：Git客户端通过 report-status-v2协议接收到服务端真实的操作行为，在服务端创建了代码评审（如：refs/changes/123/head）。
在如下的示例中，有两个角色参与到协同中。开发者向服务端仓库推送，创建了编号为123的代码评审（CR#123），评审者亦能下载、修改和上传代码评审中的提交。
上图中的开发者，执行如下操作：
∙ 开发者将远程上游仓库克隆到本地，并在本地创建开发分支。
◦ git clone https://codeup.aliyun.com/$group/$repo.git
∙ 开发者创建本地分支（topic）。
◦ git switch -c topic master
∙ 在本地分支中开发。
◦ git add <file>
◦ git commit -s
∙ 执行特别的推送命令。如下所示，将本地提交推送到远端不存在也不会被创建的一个虚拟分支（引用）中，该虚拟分支的格式为refs/for/<目标分支>/<本地分支>。服务端识别这个特殊的推送操作，在服务端创建代码评审。
◦ git push origin HEAD:refs/for/master/topic
∙ 上述推送命令的特殊目标分支被服务端识别，自动创建代码评审（如编号 123 的代码评审：CR #123）。
∙ 本地仓库继续修改，创建或更新提交。
◦ git add <file>
◦ git commit -s
∙ 执行同样的推送命令，刷新远程仓库中的代码评审（CR #123）。
上图中的代码评审者参与代码评审过程中，可以下载代码评审（CR #123）到本地进行线下评审，亦可参与代码协同，更新 CR #123 上的提交。说明如下：
∙ 评审者可以下载编号123 的代码评审相关提交到本地，进行线下评审。
◦ git fetch origin refs/changes/123/head
∙ 评审者创建本地分支（如 rev-branch）。
◦ git switch -c rev-branch FETCH_HEAD
∙ 评审者在本地分支创建新提交。
◦ git add <file>
◦ git commit -s --fixup HEAD
∙ 评审者执行特殊推送命令，更新代码评审中的提交，供原作者参考。该命令中使用了特别的推送参数 -o review=123用于更新指定代码评审。示例如下：
◦ git push -o review=123 origin HEAD:refs/for/master
b）优势和缺点
AGit-Flow的优势：
∙ 人人皆可贡献，只读用户也可以参与代码开发，适合于开源场景。
∙ 同时也适合于企业私有仓库的开发场景。因为不存在仓库派生，不像 GitHub 工作流那样因派生熔断导致仓库授权失去管控，因此既适合于开源代码开发场景，又适合于企业私有项目的开发场景。
∙ 开发者工作在同一个仓库中，服务端仓库无需同步操作。即不需要 GitHub 工作流那样要进行上游仓库、派生仓库、本地仓库的三方同步操作。
∙ 操作步骤简化，命令行推送操作直接创建代码评审，无需通过 web 界面创建代码评审。
∙ 适合于多仓库项目的场景。可以参考 Android 项目管理多仓库的方案。
AGit-Flow 的缺点：Git 推送命令行比较长，使用特殊的目标引用（refs/for/<branch>/<topic>）或特殊的推送参数，需要学习和适应。
4）推送评审模式
基于阿里云贡献给Git 社区的两大核心功能（服务端 proc-receive 挂钩和客户端 report-status-v2 扩展），阿里云·云效代码平台创造了推送评审模式，实现对仓库分支、标签的全生命周期管理。
推送评审模式内部测试中，将于2023年底正式商用。
推送评审的使用方法：
∙ 向已有分支推送：不更新分支，而是创建一个新的代码评审，或更新已有的相关代码评审。
∙ 推送操作欲创建分支/标签：不直接创建分支/标签，而是创建一个审核单，审核通过后执行分支/标签的创建操作。
∙ 推送操作欲删除分支/标签：不直接删除分支/标签，而是创建一个审核单，审核通过后执行分支/标签的删除操作。
∙ 向分支强制推送：不更新分支，而是创建一个审核单，审核通过后执行分支的强制更新操作。
∙ 管理员可以在推送命令中加入参数绕过推送评审，使得推送操作直接生效。如：
◦ git push -o review=no origin <新分支> :<待删除分支>
◦ git push -o review=no --force-with-lease
带你读《代码管理实践10讲》——一、量体裁衣，寻找适合你团队的代码协同模式（2）:https://developer.aliyun.com/article/1480953
