三类代码协同模式，Git大神告诉你到底如何选。Git代码协同模式基础
GitHub 应该是受到了 git 命令git request-pull的启发，将代码评审称为拉取请求（pull request, PR）。
GitLab 因为代码评审最终被合并（也支持变基 rebase）到目的分支，因而称其为合并请求（merge request, MR）。
阿里云·云效的代码平台，代码评审不但用于分支提交变更的评审，也将支持分支创建、分支删除、强制推送行为的评审，因此云效代码平台将代码评审称为变更请求（change request），简记为 CR。
GitHub-Flow：开源社区标配的协同模型
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
git commit -s
将本地分支推送到远程派生仓库。
git push -u -f upstream HEAD
创建代码评审（pull request）。即：通过 GitHub 的 Web 界面，从远程派生仓库向远程上游仓库创建 pull request。
本地仓库中新的改动（提交）再次推送到远程的派生仓库，会自动刷新代码评审中的提交。
优势和缺点
满足了开源项目人人皆可贡献的目标。在2008年，仓库派生是基于原生 Git 实现开源协同的最易用的方案。
易于管理。将代码管理工作化整为零，每个派生仓库由派生者自行管理，开源项目的负责人无需进行复杂的授权管理和分支管理。
派生仓库是一个独立的拷贝，不会受到上游变更（许可证变更、开放性变更、授权变更等）的影响。
仓库同步操作复杂。同步操作涉及到远程上游仓库、远程派生仓库、本地克隆仓库的三方数据同步，开发者要熟悉git remote、git rebase等命令。
派生熔断导致仓库授权失去管控。在仓库的开放性发生变更（例如从公开项目转换为私有项目），主项目和派生项目之间的派生关系被切断，成为没有派生关系的不同的项目，派生项目的管理权也从主项目自动交接给派生项目的用户。
不适合于多仓库类型的项目（如 Android 项目）。由于多仓库的存在，放大了派生仓库和上游仓库同步的复杂度。
派生仓库导致服务端存储出现冗余。
分支评审：仅适用于私有仓库的协同模型
分支评审模式的使用
管理员：即仓库的维护者，具有代码仓库最高权限，可以创建分支、删除分支、更新分支，以及向分支强制推送。
开发者：具有仓库的读写权限，除了不具备删除仓库等危险操作的权限之外，和管理员一样，具有创建分支、删除分支、更新分支，以及向分支强制推送的权限。
贡献者：没有仓库的写权限，只拥有读权限。
特性分支（topic branch）：为完成某一功能开发而创建的临时分支，通常基于主干分支创建。不同的项目对于特性分支可能有不同的命名规范，例如：topic/、feature/。 热修复分支（hotfix branch）：为修复已发布的历史版本的缺陷，基于历史发布版本（如 v1.0 版本）创建的分支。不同的项目对于热修复分支可能有不同的命名规范，例如：hotfix/。
开发者将远程仓库克隆到本地：
git clone https://example.com/group/repo.git
本地创建分支，如 topic/1分支：
git switch -c topic/1
在本地分支中开发。
git add
git commit -s
将本地topic/1分支推送到远程服务器上。
git push -u origin HEAD
开发者访问 Web 界面，选择从topic/1分支向master分支创建代码评审（如编号 123 的代码评审CR #123）。
本地仓库继续修改，创建或更新提交。
git add
git commit -s
执行推送命令，自动刷新远程仓库中的代码评审（CR #123）。
git push
代码评审通过，从 Web 界面访问 CR#123，点击合入完成分支topic/1到分支master的合入。
分支topic/1合入后，可以手工删除该分支。
GitLab 的保护分支功能
通过输入名称通配符，确保与之匹配的分支被加以保护。
可以设置被保护的分支必须使用代码评审才能够合入，不能直接推送。
可以设置被保护的分支不能够被强制推送，管理员也不例外。
优势和缺点
如果某个特性的开发周期比较长，创建一个长期存在的特性分支，便于开发者能够随时执行推送命令将本地提交推送到服务端，避免本地误操作而丢失数据。
如果某个特性由多人协同开发，设置一个特性分支，便于多个用户进行工作协同。
如果开发者无论是否必须、无论特性的大小，都采用分支评审模式，且不能及时删除过时的特性分支，就会在服务端遗留大量过时的分支。仓库中过多的特性分支和仓库的核心分支（主干、维护分支）混杂，会给开发者带来困惑，也会导致用户操作过程的性能下降。
缺乏有效的分支授权管控，无法限制对于非保护分支的推送、创建、删除权限的管控，可能导致特性分支被误删，或者特性分支因多人协同时强制推送被覆盖，造成代码丢失、协同效率的下降。
分支评审模式的改进
AGit-Flow：兼顾开源和私有项目的集中式协同模型
AGit 工作流的使用
用户向仓库的特殊引用（如refs/for/master）推送，生成代码评审。其中特殊引用refs/for/master在服务端并不存在，也不会因为用户的推送操作而被创建，用户的推送操作被服务端扩展程序接管，创建代码评审。
客户端收到服务端操作的真实结果，并向用户报告。例如：Git客户端通过report-status-v2协议接收到服务端真实的操作行为，在服务端创建了代码评审（如：refs/changes/123/head）。
开发者将远程上游仓库克隆到本地，并在本地创建开发分支。
git clone https://codeup.aliyun.com/$group/$repo.git
开发者创建本地分支（topic）。
git switch -c topic master
在本地分支中开发。
git add
git commit -s
执行特别的推送命令。如下所示，将本地提交推送到远端不存在也不会被创建的一个虚拟分支（引用）中，该虚拟分支的格式为refs/for//。服务端识别这个特殊的推送操作，在服务端创建代码评审。
git push origin HEAD:refs/for/master/topic
上述推送命令的特殊目标分支被服务端识别，自动创建代码评审（如编号 123 的代码评审：CR #123）。
本地仓库继续修改，创建或更新提交。
git add
git commit -s
执行同样的推送命令，刷新远程仓库中的代码评审（CR #123）。
评审者可以下载编号 123 的代码评审相关提交到本地，进行线下评审。
git fetch origin refs/changes/123/head
评审者创建本地分支（如 rev-branch）。
git switch -c rev-branch FETCH_HEAD
评审者在本地分支创建新提交。
git add
git commit -s –fixup HEAD
评审者执行特殊推送命令，更新代码评审中的提交，供原作者参考。该命令中使用了特别的推送参数-o review=123用于更新指定代码评审。示例如下：
git push -o review=123 origin HEAD:refs/for/master
优势和缺点
人人皆可贡献，只读用户也可以参与代码开发，适合于开源场景。
同时也适合于企业私有仓库的开发场景。因为不存在仓库派生，不像 GitHub 工作流那样因派生熔断导致仓库授权失去管控，因此既适合于开源代码开发场景，又适合于企业私有项目的开发场景。
开发者工作在同一个仓库中，服务端仓库无需同步操作。即不需要 GitHub 工作流那样要进行上游仓库、派生仓库、本地仓库的三方同步操作。
操作步骤简化，命令行推送操作直接创建代码评审，无需通过 web 界面创建代码评审。
适合于多仓库项目的场景。可以参考 Android 项目管理多仓库的方案。
推送评审模式
向已有分支推送：不更新分支，而是创建一个新的代码评审，或更新已有的相关代码评审。
推送操作欲创建分支/标签：不直接创建分支/标签，而是创建一个审核单，审核通过后执行分支/标签的创建操作。
推送操作欲删除分支/标签：不直接删除分支/标签，而是创建一个审核单，审核通过后执行分支/标签的删除操作。
向分支强制推送：不更新分支，而是创建一个审核单，审核通过后执行分支的强制更新操作。
管理员可以在推送命令中加入参数绕过推送评审，使得推送操作直接生效。如：
git push -o review=no origin :
git push -o review=no –force-with-lease
设计团队的代码协同工作流
团队能力和项目类型评估
是否开源？
维护者。维护者可以是一个人或者一个团队承担项目维护者的职责，维护者具有仓库读写和管理权限。管理权限包括：批准代码评审通过，合并代码评审等。
贡献者。贡献者具有只读权限，需要通过 GitHub-Flow 或者 AGit-Flow 方式向仓库贡献代码。
git push origin HEAD:refs/drafts//
是否有旧版本需要维护？
是否使用CI和代码评审？
多个开发者向服务端仓库的同一个分支推送，先推送者成功，后推送者遇到非快进式推送被拒绝，需要采用正确的行为规范，避免强制推送造成其他人的提交被覆盖、丢失。推荐的操作方式是：
推送之前先执行拉取和变基操作：git pull –rebase。
再执行推送操作：git push。
使用保护分支功能，设置被保护的分支不能强制推送，不能被删除。这样向保护分支推送时需要采用上面的操作建议，先和服务器同步、变基操作，再推送。
当发现推送了错误的提交，希望采用强制推送覆盖服务器上推送的提交时，不要使用git push –force，而是使用git push –force-with-lease命令，为强制推送增加一份保险。注意：替换的服务器端提交如果已被他人获取，强制推送可能为他人带来困扰。
根据CI和代码评审的频率来判断项目的规模
项目复杂度 = 每日新建CR数量 / 每日串行CI构建数量 每日串行CI构建数量 = 8小时 / 单次CI构建时间
项目复杂度 = NT / 8
N：每日新建 CR 数量。
T：单次CI构建时间（单位：小时）。
示例：小型项目（无维护分支）协同规范
项目成员管理
管理员：由一位或几位核心成员担任，具有对仓库完全的读写权限。
开发者：固定的项目成员，对于仓库中非保护分支具有完全的读写权限。
贡献者：团队之外的成员属于贡献者，仅有仓库的只读权限。
分支的命名和管理
可以使用通配符“*”设置保护分支，即所有分支均被保护。
管理员和开发者能够在仓库中创建新分支，或者在推送评审模式启用下，任何人均可通过创建评审单的方式创建新分支。
如果所有分支均被保护，则开发者创建的特性分支也需要使用 AGit-Flow 工作流创建代码评审，将提交合并到特性分支中。
向特性分支发起的代码评审，默认采用变基（rebase）方式合并，以避免在特性分支产生合并提交。
向主干分支发起的代码评审，默认采用非快进合并（no-ff merge）方式合并。这种方式一定会产生一个合并提交，在合并提交中记录代码评审 CR 的编号和 CR 的描述信息。
特性分支合入到主干分支时，默认选择合并后删除分支，避免过时的特性分支在仓库中堆积。
创建代码评审
持续集成（CI）
针对如下场景触发持续集成：
向主干分支、特性分支的代码推送，触发持续集成。
创建和更新 CR，触发持续集成。
CR 的目标分支被更新，触发持续集成。为避免 CR 构建规模造成的资源浪费，会检查开启的 CR 数量，当仓库复杂度超过阈值（NT/8 >= 1）则应关闭 CR 随目标分支变更而自动构建的设置。
示例：大型私有项目（含维护分支）协同规范
项目成员管理
管理员：由一位或几位核心成员担任，具有对仓库完全的读写权限。
开发者：固定的项目成员，对于仓库中非保护分支具有完全的读写权限。
贡献者：团队之外的成员属于贡献者，仅有仓库的只读权限。
分支的命名
一条主干分支：master（或main），同时作为仓库的默认分支，由仓库管理员在仓库初始化时创建。
一条或多条维护分支：作为对一个或多个已发布版本的缺陷修复，仅合入缺陷修复提交，不合入新功能。可选的名称有：maint、maint-1.0、release/1.0、release/2.0等。Git项目使用 maint作为维护分支名，因为按照字母序，维护分支maint排在主干分支master之前，意味着更稳定。
一条集成分支：该分支作为主干分支的集成分支，每一次集成的时候自主干分支重置，批量合入已经通过评审的 CR。批量合入后触发CI构建。Git项目中集成分支命名为next，字母序排在master之后，视为不稳定的分支。
分支管理规范
可以使用通配符“*”设置保护分支，即所有分支均被保护。
管理员和开发者能够在仓库中创建新分支，或者在推送评审模式启用下，任何人均可通过创建评审单的方式创建新分支。
因为所有分支被保护，开发者创建的特性分支、hotfix分支等也需要使用 AGit-Flow 工作流创建代码评审，将提交合并到相关分支中。
发现历史版本的缺陷后，基于存在缺陷最老的维护分支进行缺陷修复。
可以采用创建 hotfix 分支的分支评审模式，或者采用 GitHub Flow 或者 AGit Flow 模式发起针对维护分支的代码评审。hotfix 分支的命名示例：hotfix/。
向维护分支发起的代码评审通过之后，合入相应的维护分支。之后将修复的维护分支逐级合并到更高版本的维护分支，将缺陷修复“扩散”到所有版本中，即 “merging upwards”。
将修复后的最新维护分支合并到主干分支。
将通过评审的多个 CR 自动或手工合入集成分支（如next分支）。
更新后的集成分支触发构建。
集成分支构建成功后，通过界面发起集成分支到主干分支的合并请求。
中大型项目设置了集成分支，因此针对主干分支的代码评审不直接合入主干分支。 在集成分支（如next分支）CI构建通过之后，重新合并到主干分支（以确保合并提交的提交说明的目标分支从next调整为master），更新主干分支提交，并触发构建。
向特性分支发起的代码评审，采用变基（rebase）方式合并，避免在特性分支产生合并提交。
向主干分支发起的代码评审，采用非快进合并（no-ff merge）方式合并。这种方式一定会产生一个合并提交，在合并提交中记录代码评审 CR 的编号和 CR 的描述信息。
特性分支合入到主干分支时，选择合并后删除（可以设置为默认开启），避免过时的特性分支在仓库中堆积。
创建代码评审
持续集成（CI）
向主干分支、集成分支、特性分支、维护分支的代码推送，触发持续集成。
创建和更新 CR，触发持续集成。
CR 的目标分支被更新，不触发 CR 的持续集成，以降低 CR 构建的复杂度。
参考链接：
[1]https://www.kubernetes.dev/docs/guide/github-workflow/
本文来自博客园，作者：古道轻风，转载请注明原文链接：https://www.cnblogs.com/88223100/p/How-do-you-choose-the-three-types-of-code-collaboration-modes.html