带你读《代码管理实践10讲》——一、量体裁衣,寻找适合你团队的代码协同模式(1)

简介: 带你读《代码管理实践10讲》——一、量体裁衣,寻找适合你团队的代码协同模式(1)

——三类代码协同模式,Git大神告诉你到底如何选

1. Git代码协同模式基础

为团队规划研发协同模式之前,有必要了解Git的几种协同模型。

 

其中多种协同模型中使用了代码评审。代码评审在不同的代码平台有不同的称谓。

 

∙        GitHub应该是受到了 git 命令 git request-pull的启发,将代码评审称为拉取请求(pull request, PR)。

∙        GitLab因为代码评审最终被合并(也支持变基 rebase)到目的分支,因而称其为合并请求(merge request, MR)。

∙        阿里云·云效的代码平台,代码评审不但用于分支提交变更的评审,也将支持分支创建、分支删除、强制推送行为的评审,因此云效代码平台将代码评审称为变更请求(change request),简记为 CR

1GitHub-Flow:开源社区标配的协同模型

GitHub 2008年一经推出,就凭借其创造性的仓库派生 + pull request”的工作流征服了开源社区。这是因为这一协同模式解决了开源社区最大的痛点:仅对少数人开放代码仓库写权限和人人皆可贡献开源的矛盾。

aGitHub 工作流的使用

对于开源项目的参与者,可以划分为两类角色:维护者和贡献者。

 

∙        维护者:具有代码仓库最高权限,可以创建分支、删除分支、更新分支,以及向分支强制推送。

∙        贡献者:没有仓库的写权限,只拥有读权限,不能向代码仓库直接推送。

GitHub 创造了仓库派生这一机制,解决了代码仓库的只读用户向代码仓库贡献的途径。我们以 k8s 社区为例,介绍 GitHub 工作流。

 

(图示摘自 https://www.kubernetes.dev/docs/guide/github-workflow/

 

image.png  

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 remotegit rebase等命令。

∙        派生熔断导致仓库授权失去管控。在仓库的开放性发生变更(例如从公开项目转换为私有项目),主项目和派生项目之间的派生关系被切断,成为没有派生关系的不同的项目,派生项目的管理权也从主项目自动交接给派生项目的用户。

∙        不适合于多仓库类型的项目(如 Android 项目)。由于多仓库的存在,放大了派生仓库和上游仓库同步的复杂度。

∙        派生仓库导致服务端存储出现冗余。

上述缺点,尤其是派生熔断导致仓库授权失去管控,无法被企业管理者所接受。因此,GitHub 工作流只适合于外部开源或者企业内部开源项目,而不适合企业私有项目。


 

2分支评审:仅适用于私有仓库的协同模型

GitHub 的派生工作流会因为仓库可见性从公开变为私有导致派生熔断,造成仓库授权失去管控,因此派生仓库协同模式通常不被企业所接受。进而,被所有代码平台所支持的分支评审模式自然成为企业私有仓库协同的最直观的选择。

a分支评审模式的使用

企业私有代码仓库的协同者通常包含三类角色:管理员、开发者、贡献者。

 

∙        管理员:即仓库的维护者,具有代码仓库最高权限,可以创建分支、删除分支、更新分支,以及向分支强制推送。

∙        开发者:具有仓库的读写权限,除了不具备删除仓库等危险操作的权限之外,和管理员一样,具有创建分支、删除分支、更新分支,以及向分支强制推送的权限。

∙        贡献者:没有仓库的写权限,只拥有读权限。

上述三个角色中,只有开发者和管理者拥有写权限,因此只有这两种角色才能够使用分支评审模式参与代码仓库的协同。

 

采用分支评审模式协同,开发者在服务端仓库中创建临时分支,将本地提交推送到相应的临时分支上,再从该临时分支创建到目标分支的代码评审。临时分支通常在代码合入后清除。用户在服务端创建的临时分支,根据目标分支的不同,有着不同的名称。如:

 

∙        特性分支(topic branch):为完成某一功能开发而创建的临时分支,通常基于主干分支创建。不同的项目对于特性分支可能有不同的命名规范,例如:topic/<name>feature/<name>

∙        热修复分支(hotfix branch):为修复已发布的历史版本的缺陷,基于历史发布版本(如 v1.0 版本)创建的分支。不同的项目对于热修复分支可能有不同的命名规范,例如:hotfix/<name>

 

 

下面的示意图演示了一个开发者如何通过分支模式将特性分支(如 topic/1)合入到主干分支(如 master)。

image.png

说明如下:

∙        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合入后,可以手工删除该分支。

 

 

bGitLab 的保护分支功能

保护分支功能最早由GitLab 实现,目的是确保分支能够严格采用分支评审模式进行协同。

 

∙        通过输入名称通配符,确保与之匹配的分支被加以保护。

∙        可以设置被保护的分支必须使用代码评审才能够合入,不能直接推送。

∙        可以设置被保护的分支不能够被强制推送,管理员也不例外。

保护分支由管理员进行设置,通常仅对代码仓库的主干分支、维护分支进行保护,而不对特性分支进行保护。

c优势和缺点

分支评审模式的优点:

 

∙        如果某个特性的开发周期比较长,创建一个长期存在的特性分支,便于开发者能够随时执行推送命令将本地提交推送到服务端,避免本地误操作而丢失数据。

∙        如果某个特性由多人协同开发,设置一个特性分支,便于多个用户进行工作协同。

分支评审模式的缺点:

 

∙        如果开发者无论是否必须、无论特性的大小,都采用分支评审模式,且不能及时删除过时的特性分支,就会在服务端遗留大量过时的分支。仓库中过多的特性分支和仓库的核心分支(主干、维护分支)混杂,会给开发者带来困惑,也会导致用户操作过程的性能下降。

∙        缺乏有效的分支授权管控,无法限制对于非保护分支的推送、创建、删除权限的管控,可能导致特性分支被误删,或者特性分支因多人协同时强制推送被覆盖,造成代码丢失、协同效率的下降。

d分支评审模式的改进

采用AGit-Flow 协同模式,直接通过命令行创建代码评审,而不在仓库中创建临时分支,可以解决了分支评审模式中特性分支过多、混乱的问题。

 

至于分支评审模式缺乏对特性分支创建、删除、强制更新的授权,阿里云·云效代码平台提供推送评审模式,实现自助式分支管理,以解决代码仓库中分支管理无序的难题。

3AGit-Flow:兼顾开源和私有项目的集中式协同模型

阿里巴巴内部的代码平台在2019年实现了一种集中式工作流——不需要仓库派生,就可以让只读用户贡献代码。这种集中式工作流既适合于开源项目,又适合于私有项目。因其核心实现基于阿里云代码团队定制版的GitAGit),因此将此工作流命名为AGit Flow

 

AGit Flow在设计上参考了 Gerrit,使用体验和 Gerrit 类似。在2020年,阿里巴巴将这一成果核心代码贡献到Git社区,对Git服务端和Git客户端能力进行了扩展。参见:《Git2.29让Git成功“牵手”Gerrit

 

20236月,由阿里云代码团队参与建设的AtomGit开源平台上线,标志着首次将 AGit 工作流带入到了开源社区(atomgit.com)。

aAGit 工作流的使用

AGit 工作流在设计上参考了 Gerrit

 

Gerrit 是谷歌开发的代码平台,被AndroidOpenStack 等项目拿来管理各自的研发协同。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),评审者亦能下载、修改和上传代码评审中的提交。

 

image.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)。

 

上图中的代码评审者参与代码评审过程中,可以下载代码评审(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

相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
云原生实践公开课
课程大纲 开篇:如何学习并实践云原生技术 基础篇: 5 步上手 Kubernetes 进阶篇:生产环境下的 K8s 实践 相关的阿里云产品:容器服务&nbsp;ACK 容器服务&nbsp;Kubernetes&nbsp;版(简称&nbsp;ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情:&nbsp;https://www.aliyun.com/product/kubernetes
目录
相关文章
|
4天前
|
持续交付 开发工具 Android开发
带你读《代码管理实践10讲》——一、量体裁衣,寻找适合你团队的代码协同模式(2)
带你读《代码管理实践10讲》——一、量体裁衣,寻找适合你团队的代码协同模式(2)
48 0
|
4天前
|
Linux 开发工具 Android开发
带你读《代码管理实践10讲》——二、新一代高效Git协同模型AGit-Flow详解
带你读《代码管理实践10讲》——二、新一代高效Git协同模型AGit-Flow详解
24 0
|
4天前
|
安全 测试技术 开发工具
带你读《代码管理实践10讲》——三、评审协同如何提效,我们团队的4点思考
带你读《代码管理实践10讲》——三、评审协同如何提效,我们团队的4点思考
25 1
|
4天前
|
敏捷开发 安全 测试技术
带你读《代码管理实践10讲》——五、重评审还是轻评审,企业该如何选择代码评审模式?
带你读《代码管理实践10讲》——五、重评审还是轻评审,企业该如何选择代码评审模式?
41 0
|
4天前
|
Shell 开发工具 git
云效代码管理可以通过以下步骤统一更换地址链接
【1月更文挑战第21天】【1月更文挑战第102篇】云效代码管理可以通过以下步骤统一更换地址链接
124 1
|
8月前
|
运维 安全 数据可视化
免费托管代码到云效代码管理Codeup
本场景介绍如何提交代码到云效代码管理Codeup。云效Codeup提供免费、不限容量的云上代码托管服务,您无需担心计费问题。
744 0
|
4天前
|
敏捷开发 Serverless 测试技术
云效产品使用常见问题之代码管理单文件超过200m无法上传如何解决
云效作为一款全面覆盖研发全生命周期管理的云端效能平台,致力于帮助企业实现高效协同、敏捷研发和持续交付。本合集收集整理了用户在使用云效过程中遇到的常见问题,问题涉及项目创建与管理、需求规划与迭代、代码托管与版本控制、自动化测试、持续集成与发布等方面。
|
4天前
|
Shell 开发工具 git
云效代码管理可以通过以下步骤统一更换地址链接
云效代码管理可以通过以下步骤统一更换地址链接
42 3
|
4天前
|
Java Serverless Maven
云效代码管理问题之代码仓库配置需要评审如何解决
云效仓库是阿里云提供的代码托管和版本控制服务,支持Git等多种版本管理工具;本合集聚焦于云效仓库的使用技巧、团队协作流程以及常见问题解答,旨在帮助开发者更高效地进行代码管理和协作开发。
1759 0
|
架构师 开发工具 开发者
《开发者评测》之云效代码管理Codeup评测活动获奖名单
云效代码管理Codeup评测活动获奖名单出炉啦!