git配了公钥还是没权限_从 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 的流程。