带你读《代码管理实践10讲》——一、量体裁衣，寻找适合你团队的代码协同模式（1）：https://developer.aliyun.com/article/1480954
2. 设计团队的代码协同工作流
基于前面介绍的代码协同模式，企业/团队根据项目的实际情况可以灵活定制自己的代码协同工作流。通过对以下问题的回答，可以找出最适合的代码协同工作流。
1）团队能力和项目类型评估
是否开源？
开源包括针对外部的代码开源，还包括企业内部开源（内源）。
如果代码仓库选择了开源（无论是外部开源，还是内源），为管理方便可以在仓库中仅定义两种用户角色：
∙ 维护者。维护者可以是一个人或者一个团队承担项目维护者的职责，维护者具有仓库读写和管理权限。管理权限包括：批准代码评审通过，合并代码评审等。
∙ 贡献者。贡献者具有只读权限，需要通过 GitHub-Flow 或者 AGit-Flow 方式向仓库贡献代码。
对于复杂的需要多人协同开发的特性，可以采用 GitHub-Flow 模式。通过创建的派生仓库进行多人协同开发，开发完毕创建向上游仓库的代码评审。代码评审通过，将提交合入到上游代码仓库。
对于简单的特性开发，建议采用 AGit-Flow 模式，用户执行 git 推送命令，直接在服务端创建代码评审。
对处于开发中尚不具备合入质量的提交，为了避免本地数据丢失，或者希望在服务端触发持续构建（CI）检查代码质量，可以通过如下推送命令在服务端创建草稿模式的代码评审：
git push origin HEAD:refs/drafts//
草稿状态的代码评审不能被合入，但是可以触发CI构建，可以进行代码评审。
是否有旧版本需要维护？
通常互联网线上应用采用持续部署（CD）、主干分支发布。这种类型的项目一旦发现线上缺陷，直接在项目的主干分支上修复缺陷，修复缺陷的提交连同新特性一同发布到线上。这种类型的项目不需要对旧版本进行维护。
有的项目无法采用持续部署、持续发布，新版本有较长的开发周期，就需要对已发布的一个或多个版本进行维护。这样的项目就需要在代码仓库中存在一个或多个维护分支。例如：安卓手机的 Android 系统、苹果手机的 iOS 系统通常在每年发布一个大版本，历史发布版本提供长达几年的维护期，这就需要在产品的代码仓库中创建一个或多个维护分支。
不同的项目对于维护分支可能有不同的命名规范，例如：maint、maint-2.0、maint-3.0。
是否使用CI和代码评审？
使用持续构建（CI）和代码评审，可以确保贡献者提交的正确性和代码质量，是软件项目高质量交付的利器。缺乏CI能力，也可以使用代码评审，不过缺乏CI的代码评审更加消耗评审人的时间，且难以保证代码的正确性。
对于缺乏代码评审文化、缺乏单元测试、不具备CI条件的项目，往往跳过代码评审，这种类型的项目通常采用类似CVS、SVN的共享分支协同模式。
即使采用代码评审的项目，对于多人协同开发的复杂特性通常创建一个长期的特性分支，多人在同一个特性分支进行代码协同时，通常也采用共享分支协同模式。
对于共享分支协同的建议：
∙ 多个开发者向服务端仓库的同一个分支推送，先推送者成功，后推送者遇到非快进式推送被拒绝，需要采用正确的行为规范，避免强制推送造成其他人的提交被覆盖、丢失。推荐的操作方式是：
◦ 推送之前先执行拉取和变基操作：git pull --rebase。
◦ 再执行推送操作：git push。
∙ 使用保护分支功能，设置被保护的分支不能强制推送，不能被删除。这样向保护分支推送时需要采用上面的操作建议，先和服务器同步、变基操作，再推送。
∙ 当发现推送了错误的提交，希望采用强制推送覆盖服务器上推送的提交时，不要使用 git push --force，而是使用 git push --force-with-lease命令，为强制推送增加一份保险。注意：替换的服务器端提交如果已被他人获取，强制推送可能为他人带来困扰。
根据CI和代码评审的频率来判断项目的规模
当代码仓库的主干分支上有多个待合并的代码评审（CR），合并其中一个CR到主干，主干分支上的代码会发生变化，这会导致其他尚未合并的 CR 的构建状态变得没有意义，需要重新执行构建以确保正确性。
总的构建规模和CR数量关系为 O(n2) ，庞大的CI构建规模造成巨大的时间成本、计算成本的浪费，此外CR需以排队构建方式合入主干分支，导致项目协同规模受限。
我们可以采用下面的公式判断项目协同规模，决定是否采用集成分支以并行方式合入代码、降低 CI 构建数量。
项目复杂度 = 每日新建CR数量 / 每日串行CI构建数量
每日串行CI构建数量 = 8小时 / 单次CI构建时间
或简记为：
项目复杂度 = NT / 8
其中：
∙ N：每日新建 CR 数量。
∙ T：单次CI构建时间（单位：小时）。
当项目复杂度大于等于1，视为中大型项目，需要引入集成分支提升 CI 构建效率，CR先批量合并到集成分支，再合入主干。
当项目复杂度小于1，视为小型项目，仅使用主干分支即可，CR直接合入主干分支。
2）示例：小型项目（无维护分支）协同规范
对于小型项目（无维护分支），采用主干开发模式。存在一条主干（如 master分支），功能开发通过特性分支模式或者 AGit-Flow 模式创建评审，代码评审触发持续集成（CI），评审通过之后，代码直接合并到主干分支。
协同示意图如下所示，其中提交之间的箭头方向表示的是时间从老到新的方向。
a）项目成员管理
项目成员分属三个角色：管理员、开发者和贡献者。
∙ 管理员：由一位或几位核心成员担任，具有对仓库完全的读写权限。
∙ 开发者：固定的项目成员，对于仓库中非保护分支具有完全的读写权限。
∙ 贡献者：团队之外的成员属于贡献者，仅有仓库的只读权限。
b）分支的命名和管理
设置一条主干分支作为仓库的默认分支。主干分支通常命名为master或 main，由仓库管理员在仓库初始化时创建。
分支管理规范：
∙ 可以使用通配符“*”设置保护分支，即所有分支均被保护。
∙ 管理员和开发者能够在仓库中创建新分支，或者在推送评审模式启用下，任何人均可通过创建评审单的方式创建新分支。
∙ 如果所有分支均被保护，则开发者创建的特性分支也需要使用AGit-Flow 工作流创建代码评审，将提交合并到特性分支中。
∙ 向特性分支发起的代码评审，默认采用变基（rebase）方式合并，以避免在特性分支产生合并提交。
∙ 向主干分支发起的代码评审，默认采用非快进合并（no-ff merge）方式合并。这种方式一定会产生一个合并提交，在合并提交中记录代码评审 CR 的编号和 CR 的描述信息。
∙ 特性分支合入到主干分支时，默认选择合并后删除分支，避免过时的特性分支在仓库中堆积。
c）创建代码评审
可以采用三种方式创建代码评审：GitHub Flow、AGit Flow、分支评审模式。代码评审创建、更新会触发持续集成。
操作略。
d）持续集成（CI）
针对如下场景触发持续集成：
∙ 向主干分支、特性分支的代码推送，触发持续集成。
∙ 创建和更新 CR，触发持续集成。
∙ CR的目标分支被更新，触发持续集成。为避免 CR 构建规模造成的资源浪费，会检查开启的 CR 数量，当仓库复杂度超过阈值（NT/8 >= 1）则应关闭 CR 随目标分支变更而自动构建的设置。
3）示例：大型私有项目（含维护分支）协同规范
对于大型项目（含维护分支），存在一条主干（如 master分支）、一条或多条维护分支（如 maint分支）。功能开发通过特性分支模式或者 AGit-Flow 模式创建评审。
创建或更新代码评审会触发持续集成，持续集成验证通过以及代码评审通过之后，首先将代码合入到集成分支（如next分支），触发集成分支的持续集成，验证通过后再整合入主干分支。
发行版本（如v1.0.0）的缺陷修复，需要创建一条维护分支（如maint分支），基于该维护分支创建热修复分支或者使用 AGit-Flow 模式创建针对维护分支的代码评审。
针对维护分支的代码评审验证通过后，先合入到维护分支，然后将维护分支回合到主干分支，以确保在历史版本中出现的问题在主干代码中亦得到修复，相同问题不再重现。
协同示意图如下所示，其中提交之间的箭头方向表示的是时间从老到新的方向。
a）项目成员管理
项目成员分属三个角色：管理员、开发者和贡献者。
∙ 管理员：由一位或几位核心成员担任，具有对仓库完全的读写权限。
∙ 开发者：固定的项目成员，对于仓库中非保护分支具有完全的读写权限。
∙ 贡献者：团队之外的成员属于贡献者，仅有仓库的只读权限。
b）分支的命名
在仓库中设置如下常设分支：
∙ 一条主干分支：master（或 main），同时作为仓库的默认分支，由仓库管理员在仓库初始化时创建。
∙ 一条或多条维护分支：作为对一个或多个已发布版本的缺陷修复，仅合入缺陷修复提交，不合入新功能。可选的名称有：maint、maint-1.0、release/1.0、release/2.0等。Git项目使用 maint作为维护分支名，因为按照字母序，维护分支maint排在主干分支master之前，意味着更稳定。
∙ 一条集成分支：该分支作为主干分支的集成分支，每一次集成的时候自主干分支重置，批量合入已经通过评审的 CR。批量合入后触发CI构建。Git项目中集成分支命名为next，字母序排在 master之后，视为不稳定的分支。
c）分支管理规范
保护分支的设置：
∙ 可以使用通配符“*”设置保护分支，即所有分支均被保护。
∙ 管理员和开发者能够在仓库中创建新分支，或者在推送评审模式启用下，任何人均可通过创建评审单的方式创建新分支。
∙ 因为所有分支被保护，开发者创建的特性分支、hotfix分支等也需要使用 AGit-Flow 工作流创建代码评审，将提交合并到相关分支中。
维护分支的管理规范：
∙ 发现历史版本的缺陷后，基于存在缺陷最老的维护分支进行缺陷修复。
∙ 可以采用创建 hotfix 分支的分支评审模式，或者采用 GitHub Flow 或者 AGit Flow 模式发起针对维护分支的代码评审。hotfix 分支的命名示例：hotfix/。
∙ 向维护分支发起的代码评审通过之后，合入相应的维护分支。之后将修复的维护分支逐级合并到更高版本的维护分支，将缺陷修复“扩散”到所有版本中，即“merging upwards”。
∙ 将修复后的最新维护分支合并到主干分支。
集成分支管理规范：
∙ 将通过评审的多个 CR 自动或手工合入集成分支（如 next分支）。
∙ 更新后的集成分支触发构建。
∙ 集成分支构建成功后，通过界面发起集成分支到主干分支的合并请求。
主干分支管理规范：
∙ 中大型项目设置了集成分支，因此针对主干分支的代码评审不直接合入主干分支。
∙ 在集成分支（如 next分支）CI构建通过之后，重新合并到主干分支（以确保合并提交的提交说明的目标分支从 next调整为 master），更新主干分支提交，并触发构建。
特性分支规范：
∙ 向特性分支发起的代码评审，采用变基（rebase）方式合并，避免在特性分支产生合并提交。
∙ 向主干分支发起的代码评审，采用非快进合并（no-ff merge）方式合并。这种方式一定会产生一个合并提交，在合并提交中记录代码评审 CR 的编号和 CR 的描述信息。
∙ 特性分支合入到主干分支时，选择合并后删除（可以设置为默认开启），避免过时的特性分支在仓库中堆积。
d）创建代码评审
可以采用三种方式创建代码评审：GitHub Flow、AGit Flow、分支评审模式。代码评审创建或更新会触发持续集成。
操作略。
e）持续集成（CI）
针对如下场景触发持续集成：
∙ 向主干分支、集成分支、特性分支、维护分支的代码推送，触发持续集成。
∙ 创建和更新 CR，触发持续集成。
∙ CR的目标分支被更新，不触发 CR 的持续集成，以降低 CR 构建的复杂度。
