携手创造，共同生长！这是我参与「日新计划 8 月更文应战」的第1天，点击查看活动详情

前语

先说一下为什么要写一下这个文章吧，由于公司关于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. 首先在长途新建一个兼并恳求

2. 挑选源分支（也便是你写代码的分支），挑选方针分支（也便是你要兼并去哪个分支），然后点击创建兼并恳求，会让你填写一些备注，还有个小的留意点，有些操作的时分有个勾选项是问你是否需要兼并完成后把源分支给删除掉，要留意看留意看留意看，依据你的需求来！！！

3. 然后发出了兼并恳求后，相关的人员（便是分配了办理权限的成员）能够看到一个兼并恳求，他就会去看，然后点击兼并（在截图便是【审查经过】【测验经过】）

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

有个要点：

假设你长途是要把A兼并去B，一般都要在本地把B兼并去A，为什么要这样做？主要是为了处理抵触，假设你不这么做，你直接在长途兼并，假设有抵触的话，往往长途是没有办法处理的。留意我说的是一般情况，像我上面说的【一个很重要的阐明】 里面就说了一些不能够这样做的场景，自己做之前要考虑一下是否也和我的场景相似！