码极系列 | Git主干与共享分支

咱们在实现团队协做流程以及 CI/CD 流程时，在很大程度上须要依赖 Git 分支这个功能，此次就来简单说说经常使用的两类分支吧。

主干

通常为 master 分支，能够理解为稳定的，可发布的，面向生产环境的分支。

咱们的项目通常都是面向生产环境的，也就是说咱们开发的功能最终都会被部署到生产环境，若是说咱们的主干不是稳定的不是面向生产环境，那这棵“树”就会越长越歪，离咱们指望的走向愈来愈远，与生产环境渐行渐远。

共享分支

视乎于团队协做流程以及 CI/CD 流程的需求，在有的时候除了主干之外，还会有专门的共享分支来接受开发人员的提交。

何时使用共享分支？

举个例子：项目建立之初，咱们为项目创建 Git 仓库，默认的咱们获得了一个 master 分支，在咱们准备好项目了基建（如搭建目录、文档等）后，就能够撰写第一个提交。在正式进入开发阶段以后，能够基于 master checkout 一个名为 develop 的分支，以后全部的功能分支都基于 develop checkout，开发好的功能分支再合并到 develop 分支，那么 develop 就能够被称为共享分支。

在完成某个阶段的开发工做后，develop 的改动被确认没问题以后，会被合并到 master。

你或许会以为很奇怪，那也没啥特别的，是的，毕竟不管分支的名字是什么，它始终都是一个普通的分支而已，你不该该从命名去理解，而是从这个分支的使命去理解，从整个流程上去理解。

搞事情？没门儿！不当心？不用怕！

我就是要搞事情！我偏要在 master 开发！

哎呦喂，一个不当心在 master 上修改了代码，要不就偷偷的 push 上去得了！

在 Github 或是 Gitlab 都提供了分支保护功能，能够将指定的分支设置为保护分支，这里就把 master 设置为保护分支，也就是说即便你在本地的 master 分支修改了内容，但只要你没有权限，就不可能做用到托管仓库的 master 分支。

这不就是 xx flow 吗？

在业界的确已经存在了一些成熟的 flow，若是想更深刻了解比较成熟的 Git 协做流程，能够查找以下资料：

• Git flow
• Github flow
• Gitlab flow

每一个流程都有各自的特色以及适用场景，若是恰好你所在的团队或项目适用某种流程，那就用起来吧！若是这些流程都不知足，彻底能够基于上面的流程去定制出一个符合团队或项目的流程 ，这里没有太多的教条，一切要从实际出发！

搞这些是为了什么？

不管是主干或是共享分支，都是一个个普通的 Git 分支，咱们为了实现团队协做流程以及 CI/CD 流程，才会有各类命名分支，不用把它们想得太复杂。

要搞清楚团队协做流程这部份内容的话，我我的以为若是能正确理解上面提到的三个成熟的 flow ，通常就没什么问题，剩下的就是随机应变的应用了。

预告

此次的分享是为了我以后要实现的流程作铺垫，你能够理解为前置技能吧，后续我经过项目分享 Github flow 和其 CI/CD 的流程。