运维自动化基础建设|代码分枝模型

运维自动化基础建设|代码分支模型

这是一个很大的话题，每家公司的使用的场景虽然大差不差，但是受限于历史债务以及业务线划分割裂，很难有一个站在公司角度上的统一的代码分枝模型，导致的后果也是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的模型走就行，与此同时主要分支权限控制好就足够了。

站在敏捷开发的角度出发

这块我个人感觉是仁者见仁，智者见智了。

TIPS

看到上面的描述，大家是不是觉得分支模型敲定了就万事大吉了，其实不是的，你有没有经历过以下场景

•一个代码仓库保留了上百个无效的分支•分支名称命名五花八门•每个分支对应的权限分配比较混乱•个人分支是否应该推送到远程

结合上面抛出的问题，我们应该怎么办

下期我们再来讲解下分支模型权限定义和分支命名的问题吧，实在是写不动了，有点累?

总结

比较统一的分支模型能够为后续的CI/CD打下坚实的基础，如果分支模型敲定不下来，后续的CI/CD工作可能就会变成按需,每一个工程都会有自己的一个独特要求，再次重申:"约定大于配置"。