这是一个很大的话题,每家公司的使用的场景虽然大差不差,但是受限于历史债务以及业务线划分割裂,很难有一个站在公司角度上的统一的代码分枝模型,导致的后果也是
OPS
需要在CI/CD
这块上面适配多种场景来满足需求,接下来的文档我就和大家一刻聊聊分支模型,以下描述仅代表个人观点感受。
为什么要强调分支模型,因为CI/CD
这块分分支模型息息相关,通常情况下,站在OPS
的角度,肯定是希望能有一个稳定的分支,随时随地都能发布,且不会对生产造成影响。如果没有明确好分支模型和对应的权限管理的话,大家都能对上线分支进行操作的话,真的是分分钟要弄个OPS
祭天。
另外一个层面就是大家协同的时候如何保障高效无冲突,这也是一个比较棘手的问题。
•Centralized
(集中式工作流)•Feature Branch
(功能分支工作流)•Git Flow
(Git Flow
作流)•Fork
(Fork
工作流)
Centralized
(集中式工作流)集中式工作流(Centralized
)是以中央仓库作为项目所有修改的单点实体。所有新功能的开发都是基于一个叫 master
分支进行。据说google
就是用的这种。
Feature Branch
(功能分支工作流)功能分支工作流每个用户都基于 master 分支创建一个新的功能分支,相比于集中式工作流会更加的安全以及产生更低的冲突率。
Git Flow
(Git Flow
作流)Git Flow
工作流仍然用中央仓库作为所有开发者的交互中心。和其它的工作流一样,开发者在本地工作并 push
分支到要中央仓库中。这也是当下比较主流的,被大多数公司使用的分支模型。
Fork
(Fork
工作流)Fork
工作流是指一个项目到自己的仓库中。与clone
方式不同,clone
主要是对目标仓库数据的一次拷贝。(github
中叫fork,gitlab
中叫派生)
在团队规模比较小的研发团队,如果严格按照Git Flow
模型去走,可能大家都会觉得有点别扭,在总的流程上按照Git Flow
的模型走就行,与此同时主要分支权限控制好就足够了。
这块我个人感觉是仁者见仁,智者见智了。
看到上面的描述,大家是不是觉得分支模型敲定了就万事大吉了,其实不是的,你有没有经历过以下场景
•一个代码仓库保留了上百个无效的分支•分支名称命名五花八门•每个分支对应的权限分配比较混乱•个人分支是否应该推送到远程
下期我们再来讲解下分支模型权限定义和分支命名的问题吧,实在是写不动了,有点累?
比较统一的分支模型能够为后续的CI/CD
打下坚实的基础,如果分支模型敲定不下来,后续的CI/CD
工作可能就会变成按需,每一个工程都会有自己的一个独特要求,再次重申:"约定大于配置
"。