前言

先说一下为什么要写一下这个文章吧，因为公司对于git的管理并没有很严格的要求和步骤，加上自己算个git小白，只会基本的推送拉取，所以导致在某一个月黑风高的夜晚，盲目操作导致花了很多时间去处理，这篇文章主要就说一下在公司多人协作怎么管理自己的分支，什么可以合并，什么不能合并！

git相信大家都是日常要使用的工具，在一人负责一人项目的小公司，git的操作基本上不会遇上任何问题，因为只有你自己一个提交，说不定也只有一个master分支，我翻车之前就是这样。

然后你可能进入一个相对大一点的团队，会有很多人来协作代码，这个时候你发现你再也不能提交master分支了，因为有了相对严格的权限管理，你发现你的项目仓库里面有一堆分支，但是公司却没有非常严格的git管理规范给到你，你也就拉下代码能跑就行，能开发就行，其实如果你并没有涉及到发布环节的流程也是没有问题的，但是如果你参与了发布流程，你又迷迷糊糊，那问题就很大了！！！ 下面，我先说一下我所在的公司的场景，然后可以根据我的场景给你一些启发，全局的去理解你的所在项目的分支管理：

介绍一下项目的分支

• master：这个是发布生产环境的分支，是最稳定的代码；是要发布生产环境的
• dev：这个是发布测试环境的分支，这里分支参杂的是各种要测试的迭代代码，都是最新的，并不一定是稳定的代码。是要发布qa测试环境和client测试环境
• dev-subsystem：这个是某个子系统的开发分支；或者你当成某次迭代重要功能的分支也行；反正是对于一次要发版的东西；这里面的代码但凡是去合并dev的都是还未通过测试的，合并master的时候必须是完整通过测试的状态下
• dev-subsystem-joe：这个就是开发某次迭代的功能或者子系统的时候，每个人分别要开发的功能分支，每个参与这个项目的开发者这都应该有个这种分支（如果对于某次迭代只有你自己开发，你可以不用再新建这个分支）

介绍一下对应分支的权限

• master：这个分支没有本地提交权限，只能通过远程仓库申请合并到master分支，如果没有试过远程仓库合并的，我下面再说一下
• dev：这个分支可以直接推送（如果你的项目不能推送的话，看一下下面的 【一个很重要的说明】 ）
• dev-subsystem：可直接推送
• dev-subsystem-joe：可直接推送

说一下每个分支应该做什么事情

master

接受方式：远程推送被合并代码

接受分支：dev-subsystem

会合并去什么分支：没有特定

接受远程推送被合并代码 ，这个分支一般只接收dev-subsystem远程合并过来，就是你要迭代的版本，就要合并过来这里，但是要注意，不要直接就远程申请dev-subsystem合并到master，因为你这样合并会发生很多冲突，并且你在远程还解决不了冲突。所以你的步骤要是这样的：

1. 你在本地的master分支和dev-subsystem分支要确保都是最新的，各自拉取一下最新的远程代码
2. 然后在本地把master分支合并到dev-subsystem分支，这个时候有冲突就解决，没有就万事大吉
3. 接着就把本地的dev-subsystem分支推送到远程的dev-subsystem
4. 最后就是把发起远程合并，把dev-subsystem分支合并到master分支

dev

接受方式：本地推送被合并代码

接受分支：dev-subsystem

会合并去什么分支：没有特定

接受本地被合并代码，这个一般就是你要把你要发布测试环境的dev-subsystem在本地合并到本地的dev分支，然后把dev推送远程的dev分支，步骤如下：

1. 你的本地的dev-subsystem和dev都要确保是最新的，各自拉取一下最新的远程代码
2. 然后把本地的dev-subsystem合并过去dev分支，这个过程如果有冲突要解决冲突
3. 最后提交dev到远程的dev

一个很重要的说明

如果你的dev分支也是只能被远程推送合并，不能本地推送，那么你 千万不要用本地dev合并去本地的dev-subsystem分支然后推送远程dev-subsystem，然后再远程合并dev， 因为这样会有个很严重的后果就是， 你的dev污染了你的dev-subsystem ，因为dev是有很多人提交的测试代码的，然后后面你又把dev-subsystem合过去master就会造成生产环境多出了很多人提交的测试代码（并不想那么快发上生产环境的那种）出问题，这种情况下你的解决步骤是这样：

1. 根据dev新建一个dev-copy分支
2. 然后在本地把dev-subsystem合并到本地dev-copy分支，解决冲突
3. 然后把本地dev-copy提交到远程的dev-copy
4. 然后再把远程的dev-copy远程申请合并到远程的dev分支
5. 完事之后再把dev-copy分支删除即可

dev-subsystem

接受方式：本地推送被合并代码

接受分支：dev-subsystem-joe

会合并去什么分支：dev，master

这个分支就是某个迭代分支，在这个分支开发的每个人员都要把自己被分配编写的代码完成后在本地的dev-subsystem-joe分支合并过去dev-subsystem分支，然后推送上去，步骤如下：

1. 你的本地的dev-subsystem-joe和dev-subsystem都要确保是最新的，各自拉取一下最新的远程代码
2. 然后把本地的dev-subsystem-joe合并过去dev-subsystem分支，这个过程如果有冲突要解决冲突
3. 最后提交dev-subsystem到远程的dev-subsystem

dev-subsystem-joe

会合并去什么分支：dev-subsystem

这个代码库只会合并到dev-subsystem库，其他都不会接触。

简单图示

说一下远程申请合并分支

本地合并大家都知道，就是把A分支合并去B分支，然后如果发生冲突的话，要选择A分支的代码还是B分支的代码以此解决冲突，远程合并分支也是如此，也是把A分支合并去B分支，我们看看远程合并的步骤（下面的步骤是gitee的，其实gitlab和github的也是相似的）：

1. 首先在远程新建一个合并请求

1. 选择源分支（也就是你写代码的分支），选择目标分支（也就是你要合并去哪个分支），然后点击创建合并申请，会让你填写一些备注，还有个小的注意点，有些操作的时候有个勾选项是问你是否需要合并完成后把源分支给删除掉，要注意看注意看注意看，根据你的需求来！！！

1. 然后发出了合并请求后，相关的人员（就是分配了管理权限的成员）可以看到一个合并请求，他就会去看，然后点击合并（在截图就是【审查通过】【测试通过】）

1. 然后就完成了合并，代码就合并去了你想要的分支

有个重点：

假如你远程是要把A合并去B，一般都要在本地把B合并去A，为什么要这样做？主要是为了解决冲突，如果你不这么做，你直接在远程合并，如果有冲突的话，往往远程是没有办法解决的。注意我说的是一般情况，像我上面说的【一个很重要的说明】 里面就说了一些不可以这样做的场景，自己做之前要思考一下是否也和我的场景相似！