合并分支可谓是分支操作中最为繁琐、最容易出现问题的环节。

但有些人会有疑问，一定要在其他分支上开发，开发完成再合并到主分支上吗？那如果多人协作的情况怎么办？不会出现问题吗？

在开发中，我们一般不会直接对主干进行修改，而是从开发分支，如dev分支中，创建自己的分支，在分支上进行修改。

在我的理解中，是为了保证主干上代码的干净。

保证了主干上的代码是可以直接发布或者被项目之外的人使用（例如新入职的员工，总不能给人家一个一运行就报错的代码库吧）。然后关于产品/项目的新特性和BUG修改都在不同的分支上进行开发和测试。这样规范了整个软件的开发流程。分支之间的互不影响这种特性可以增加团队合作的效率。

至于多人协作时出现的各式各样的问题，归根到底只需要记住一个点，就能大量避免远端上的问题，那就是！

在合并之前，记得要先更新合并分支的代码，避免出现提交的历史不匹配，而导致更多的冲突。

git最佳分支流程

接下来，我们就基于前面几篇，来进行一个完整的开发流程：

这篇没有H1标题了！

一般开发环境中，git会存在master主分支、release发布分支、dev开发分支，甚至还有test测试分支。

以下基于存在master主干分支、dev开发分支的情况下进行，若没有dev分支，那么建议你说服你的技术主管（我相信你可以的）

1、从远端clone项目到本地后，先切换到dev分支并在该dev分支上更新下最新代码，保证待会创建的分支的代码都是最新的：

 git pull

2、开分支：

 git branch feature-2019-6-29-testBranch

feature一般用于新功能开发

feature命名的分支，我们一般用于新功能的开发，它只与dev分支交互，开发完成并合并到dev后，就会删除该分支。

另外还有hotfix命名的分支，一般用于修复主干分支上的bug，但需要注意，由于该bug是旧版本所存在的问题，那么在dev分支上也同样存在该问题，也就代表着，修复了这个bug后，该hotfix分支的提交需要合并到master和dev两个分支上，避免后续dev分支合并master分支时出现问题。

而dev分支将作为最终开发和调试的代码库，完成后合并master分支，并发布新版本。

3、查看分支情况（以及自己正在使用的分支）：

 git branch

4、切换分支：

 git checkout featrure-2019-6-29-testBranch

5、查看分支情况（是否有提交之类的）：

总结下上面的步骤：

1、上面的步骤可以直接通过一个命令来进行创建分支，并切换分支：

 git checkout -b feature-2019-6-29-testBranch

2、在该分支上进行修改，修改完后进行添加和提交：

 git add .
 git commit -m "备注"

3、本地切换为dev分支，更新下dev为最新（因为可能其他开发人员已经合并过代码，此时你本地的dev不再是最新），为了下面的合并不受冲突：

 git checkout dev
 git pull

4、切换回来

 git checkout feature-2019-6-29-testBranch

5、将更新到最新dev合并到自己这个分支上，这一步是为了在你修改自己的分支的过程中，已经有分支合并到dev上了，如果有冲突的话，就先把dev的合并过来，然后在分支上进行冲突解决：

 git merge dev

注意，当前分支为要被合并的分支

6、如果merge后有冲突需要修改，修改后进行 添加、提交、拉取最新（如果这个分支别人也有修改，记得pull更新最新，确保不冲突）：

 git add .
 git commit -m "备注"
 git pull orgin feature-2019-6-29-testBranch

7、确认无误后，保证编译正常的情况下，就可以push这个分支到远程仓库了：

 git push origin feature-2019-6-29-testBranch

8、之后就可以在dev分支上合并自己的那个分支了（但项目不受权限控制，可以直接通过命令来合并）：

 git checkout dev
 git merge feature-2019-6-29-testBranch
 git pull
 git push dev

注意，需要先切换当前分支为要被合并的分支，如此时是dev分支。

9、当没有权限对dev进行操作的时候，则需要在页面上进行合并的操作（以GitLab为例）：

提交合并请求，给到有权限的人，去确定合并

10、至此分支操作结束，删除分支，删除分支的时候需要先切换分支为其他分支，才能进行删除：

删除本地分支：

 git branch -d feature-2019-6-29-testBranch

删除远程分支：

 git push origin --delete feature-2019-6-29-testBranch

当出现冲突的时候：

1、主干版本有新的提交，分支上也同样修改了该文件，此时在主干上pull更新到最新，然后checkout到分支上，合并主干的时候，会出现

这种情况，可以先将本地的修改存储到暂存区：

然后再合并：

再把自己的修改从暂存区拿出来：

（git stash list： 可以看到暂存区里面的东西，从而可以根据需要来获取

git stash pop: 把暂存区里面的修改取出来

git stash clear：清除暂存区 ）

这时候，文件会变成conflict状态：

修改后，再提交，再合并回主干，就不会有冲突了。

是不是真的没有H1标题

总的来说，一般开发过程中，都有一个前提，那就是不会直接使用master分支进行开发，而是由dev分支进行，有些团队在这个基础上，让各个开发人员都使用自己的dev分支，也就是说会有很多个dev分支（如dev_某某某），开发人员在开发完成，解决完冲突后，再将自己的分支合并到主开发分支（可能会使用dev分支，或者也可能会使用release发布分支）上，各自维护各自的开发分支。

后续

使用分支+merge开发，是Git在开发中最常见的开发方式，但由于每次合并都会使用merge，在本地分支的提交历史和远端的分支的提交历史不一致的情况下，此时Git会为我进行了自动合并，然后生成了一个新的提交历史，内容如“merge branch 'master' of...”，也就是产生了分叉，若不想看到这种情况，我们就会使用另一个命令git rebase来进行，该命令可以使分支间的提交历史同步，不会产生分叉，我们后面再来说。