三类代码协同模式,你要如何选?
三类代码协同模式,Git大神告诉你到底如何选。
Git代码协同模式基础
-
GitHub 应该是受到了 git 命令 git request-pull的启发,将代码评审称为拉取请求(pull request, PR)。
-
GitLab 因为代码评审最终被合并(也支持变基 rebase)到目的分支,因而称其为合并请求(merge request, MR)。
-
阿里云·云效的代码平台,代码评审不但用于分支提交变更的评审,也将支持分支创建、分支删除、强制推送行为的评审,因此云效代码平台将代码评审称为变更请求(change request),简记为 CR。
GitHub-Flow:开源社区标配的协同模型
GitHub 工作流的使用
-
维护者:具有代码仓库最高权限,可以创建分支、删除分支、更新分支,以及向分支强制推送。
-
贡献者:没有仓库的写权限,只拥有读权限,不能向代码仓库直接推送。
![图片](https://img2023.cnblogs.com/blog/27422/202308/27422-20230826124156289-1609340948.png)
-
创建派生仓库。说明:作为 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。
-
本地仓库中新的改动(提交)再次推送到远程的派生仓库,会自动刷新代码评审中的提交。
优势和缺点
-
满足了开源项目人人皆可贡献的目标。在2008年,仓库派生是基于原生 Git 实现开源协同的最易用的方案。
-
易于管理。将代码管理工作化整为零,每个派生仓库由派生者自行管理,开源项目的负责人无需进行复杂的授权管理和分支管理。
-
派生仓库是一个独立的拷贝,不会受到上游变更(许可证变更、开放性变更、授权变更等)的影响。
-
仓库同步操作复杂。同步操作涉及到远程上游仓库、远程派生仓库、本地克隆仓库的三方数据同步,开发者要熟悉 git remote、git rebase等命令。
-
派生熔断导致仓库授权失去管控。在仓库的开放性发生变更(例如从公开项目转换为私有项目),主项目和派生项目之间的派生关系被切断,成为没有派生关系的不同的项目,派生项目的管理权也从主项目自动交接给派生项目的用户。
-
不适合于多仓库类型的项目(如 Android 项目)。由于多仓库的存在,放大了派生仓库和上游仓库同步的复杂度。
-
派生仓库导致服务端存储出现冗余。
分支评审:仅适用于私有仓库的协同模型
分支评审模式的使用
-
管理员:即仓库的维护者,具有代码仓库最高权限,可以创建分支、删除分支、更新分支,以及向分支强制推送。
-
开发者:具有仓库的读写权限,除了不具备删除仓库等危险操作的权限之外,和管理员一样,具有创建分支、删除分支、更新分支,以及向分支强制推送的权限。
-
贡献者:没有仓库的写权限,只拥有读权限。
-
特性分支(topic branch):为完成某一功能开发而创建的临时分支,通常基于主干分支创建。不同的项目对于特性分支可能有不同的命名规范,例如:topic/<name>、feature/<name>。 -
热修复分支(hotfix branch):为修复已发布的历史版本的缺陷,基于历史发布版本(如 v1.0 版本)创建的分支。不同的项目对于热修复分支可能有不同的命名规范,例如:hotfix/<name>。
![图片](https://img2023.cnblogs.com/blog/27422/202308/27422-20230826124156515-2032054308.png)
-
开发者将远程仓库克隆到本地:
-
git clone 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合入后,可以手工删除该分支。
GitLab 的保护分支功能
-
通过输入名称通配符,确保与之匹配的分支被加以保护。
-
可以设置被保护的分支必须使用代码评审才能够合入,不能直接推送。
-
可以设置被保护的分支不能够被强制推送,管理员也不例外。
优势和缺点
-
如果某个特性的开发周期比较长,创建一个长期存在的特性分支,便于开发者能够随时执行推送命令将本地提交推送到服务端,避免本地误操作而丢失数据。
-
如果某个特性由多人协同开发,设置一个特性分支,便于多个用户进行工作协同。
-
如果开发者无论是否必须、无论特性的大小,都采用分支评审模式,且不能及时删除过时的特性分支,就会在服务端遗留大量过时的分支。仓库中过多的特性分支和仓库的核心分支(主干、维护分支)混杂,会给开发者带来困惑,也会导致用户操作过程的性能下降。
-
缺乏有效的分支授权管控,无法限制对于非保护分支的推送、创建、删除权限的管控,可能导致特性分支被误删,或者特性分支因多人协同时强制推送被覆盖,造成代码丢失、协同效率的下降。
分支评审模式的改进
AGit-Flow:兼顾开源和私有项目的集中式协同模型
AGit 工作流的使用
-
用户向仓库的特殊引用(如refs/for/master)推送,生成代码评审。其中特殊引用 refs/for/master在服务端并不存在,也不会因为用户的推送操作而被创建,用户的推送操作被服务端扩展程序接管,创建代码评审。
-
客户端收到服务端操作的真实结果,并向用户报告。例如:Git客户端通过 report-status-v2协议接收到服务端真实的操作行为,在服务端创建了代码评审(如:refs/changes/123/head)。
![图片](https://img2023.cnblogs.com/blog/27422/202308/27422-20230826124156368-327748491.png)
-
开发者将远程上游仓库克隆到本地,并在本地创建开发分支。
-
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)。
-
评审者可以下载编号 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
优势和缺点
-
人人皆可贡献,只读用户也可以参与代码开发,适合于开源场景。
-
同时也适合于企业私有仓库的开发场景。因为不存在仓库派生,不像 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/<branch>/<topic>
是否有旧版本需要维护?
是否使用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构建时间(单位:小时)。
示例:小型项目(无维护分支)协同规范
![图片](https://img2023.cnblogs.com/blog/27422/202308/27422-20230826124156494-233699421.png)
项目成员管理
-
管理员:由一位或几位核心成员担任,具有对仓库完全的读写权限。
-
开发者:固定的项目成员,对于仓库中非保护分支具有完全的读写权限。
-
贡献者:团队之外的成员属于贡献者,仅有仓库的只读权限。
分支的命名和管理
-
可以使用通配符“*”设置保护分支,即所有分支均被保护。
-
管理员和开发者能够在仓库中创建新分支,或者在推送评审模式启用下,任何人均可通过创建评审单的方式创建新分支。
-
如果所有分支均被保护,则开发者创建的特性分支也需要使用 AGit-Flow 工作流创建代码评审,将提交合并到特性分支中。
-
向特性分支发起的代码评审,默认采用变基(rebase)方式合并,以避免在特性分支产生合并提交。
-
向主干分支发起的代码评审,默认采用非快进合并(no-ff merge)方式合并。这种方式一定会产生一个合并提交,在合并提交中记录代码评审 CR 的编号和 CR 的描述信息。
-
特性分支合入到主干分支时,默认选择合并后删除分支,避免过时的特性分支在仓库中堆积。
创建代码评审
持续集成(CI)
针对如下场景触发持续集成:
-
向主干分支、特性分支的代码推送,触发持续集成。
-
创建和更新 CR,触发持续集成。
-
CR 的目标分支被更新,触发持续集成。为避免 CR 构建规模造成的资源浪费,会检查开启的 CR 数量,当仓库复杂度超过阈值(NT/8 >= 1)则应关闭 CR 随目标分支变更而自动构建的设置。
示例:大型私有项目(含维护分支)协同规范
![图片](https://img2023.cnblogs.com/blog/27422/202308/27422-20230826124156421-1664477239.png)
项目成员管理
-
管理员:由一位或几位核心成员担任,具有对仓库完全的读写权限。
-
开发者:固定的项目成员,对于仓库中非保护分支具有完全的读写权限。
-
贡献者:团队之外的成员属于贡献者,仅有仓库的只读权限。
分支的命名
-
一条主干分支: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/<name>。
-
向维护分支发起的代码评审通过之后,合入相应的维护分支。之后将修复的维护分支逐级合并到更高版本的维护分支,将缺陷修复“扩散”到所有版本中,即 “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