Git使用指南-进阶

上篇文章介绍了git的基本概念和用法。大致提及了多人合作使用git的一个基本流程。然而多人合作中最常见的问题就是冲突（各种意义上的）。本文只负责解决通过git管理的代码上的冲突:)

涉及到git中两种较为复杂，会产生冲突的操作——merge和rebase

冲突的产生

先来回顾一下多人协作中git常见的使用流程

1. 创建项目，提交成master分支
2. 从master创建一个新的分支，开发自己的部分
3. 开发测试完毕，提交自己的分支
4. 将自己的分支和master做合并
   上述步骤看似十分顺利，但潜藏了一些问题。具体来说，在你拉取自己的分支后，master大概率已经被其他人修改了，因为其他人也是按照这个流程进行的。此时就会出现冲突，比如你们都修改了同一个文件的同一行。或者因为你基于的master分支不是最新的，那么一些后续的更改并不在你这里，当你合并时，新旧master之间的区别也会成为冲突。

merge操作

针对上述的问题，一个解决方案就是直接将你的分支和当前的maseter进行合并，并且挨个看冲突的代码，决定保留什么。这种合并两个分支代码的操作就是merge。

merge操作适用于合并差异较大的两个分支，但在正常的开发流程中不推荐使用。根据上面的例子，由于你基于的master和当前master的差异，每一次merge你都需要手动将master近期的更新再处理一遍。

rebase操作

相较于merge，在正常开发流程中，rebase更加常用。先来介绍rebase操作的含义。

还是上面的场景，rebase操作会将这个分支的所有更新操作先取消，然后将master更新到最新，然后根据你选择（默认是全部）的这个分支的提交按时间顺序在更新后的master上进行一遍。

注意两个点：

1. rebase是可以选择提交的，此处你可以取消一些提交，还可以将多个提交合并成一个。这很重要和常见，因为在开发过程中可能会提交多次，而当开发完毕，按照规范，这些更改应该合并成一个并且按这次开发的需求来命名。
2. 此过程是将这些提交按时间顺序一个接一个提交到最新的master上的，这个过程中会产生冲突，需要挨个去解决。极端情况，10次提交都有冲突，则需要解决10次冲突。
   举个例子，假设master最初test文件是空的，老王和老李同时对这个文件进行修改。此时二人分别拉取了自己的分支。

老王先写完，将文件提交合并进master

此时老李也写完了，提交了自己的更新到自己的分支。现在需要合并进master了。老李的分支如下图。

老李直接提交合并，发现有冲突。

冲突如下，可以直接在这里解决，然后合并。这就是merge的做法，并不推荐，除了上面提到的问题，还会存在提交不规范，未合并的问题。

此时，老李选择在自己的分支上rebase master。

可以看到，冲突如下图，左边是更新后的最新master，是老王写入的。右边是老李拉取master后的一次更新，需要解决这个冲突。

此处选择的解决方法是将两边都保留，不同情况处理方法不同。

应用之后，会发现老李自己的分支后出现了两个箭头，说明老李自己的分支本地和远端不一致。因为自己本地分支更新了master。

此时不要慌，选择强制push，更新远程分支和本地一致。

完成之后再去github上提交合并请求，发现已经没有冲突了，顺利合并进去。

常见操作流程完整版

至此，我们可以得到一个多人协作git的完整版操作流程了

1. 创建项目，提交成master分支
2. 从master拉取一个开发分支，根据具体工作内容命名 feat/xxx（新增需求） fix/xxx（修复问题）等等
3. 在这个分支上进行你的工作
4. 将所有更新提交到远程同名分支
5. rebase操作，更新本地分支，将master更新为最新，合并所有提交成一个，按工作内容命名，解决冲突
6. 强制更新远程分支
7. 提交合并请求，协作者审核后合并进master

提交规范

对于分支的名称和提交信息的写法，应该遵循一些规范

分支名称

标准开头/工作内容 的格式进行填写

提交信息

标准开头: 提交内容 的格式进行填写

标准开头如下：

feat：新功能（feature）
fix：修补bug
docs：文档（documentation）
style： 格式（不影响代码运行的变动）
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
test：增加测试
chore：构建过程或辅助工具的变动