前2天群里发了张git历史图，如下：
根据提交历史，可以看出图中所有分支合并都采用merge的方式，具体merge是怎么操作的，可以阅读下边文章。
根据项目上的需求，如果要求git提交历史是比较简单的一条时间线，可以使用rebase的合并；如果没有这个要求，可以使用merge合并，其分支树是网状结构，但每个提交也都是比较明确清晰的。他们的区别，可参考git merge与 git rebase区别及实例：
rebase合并
（1）远程fetch的代码，本地没有修改，直接rebase即可；
（2）若本地对文件修改，没有add，rebase时，会提示“Cannot rebase: You have unstaged changes.Please commit or stash them.”，add后没有commit，会提示“Cannot rebase: Your index contains uncommitted changes.Please commit or stash them.”。commit后，如果没有修改同一文件，rebase不会冲突。
（3）若本地对同一个文件修改，commit后，rebase时，有2种情况：
① 如果没有修改同一位置，则可以rebase，不会产生冲突；
②如果修改了同一处，则rebase时会出现冲突，也不用怕，此时git已经进行了合并，只是没有应用自己的提交，解决办法：修改冲突的文件，然后执行add和rebase --continue操作即可。如果不小心，执行完add后执行了commit，此时本地仓库HEAD处于游离态，如何解决，后续再补充。
merge合并
merge合并也可能存在冲突，解决冲突与rebase相似，处理完冲突文件后，重新提交即可。
举例说明
假设现在有3个人（git1、git2、git3）合作开发一个项目。
（1）git1创建项目，添加index.html文件，在index文件中添加“create by git1”，提交；
git2拉取文件后，在index中添加“add by git2”，提交；
git3拉取文件后，在index中添加“add by git3”，提交；
git1拉取最新代码后，在index中添加“add by git1 add1 by git1”，如下：
提交远程仓库，分支树如下：
（2）git2在index文件中添加“add 1 by git2”，以实验冲突
此时分支树如下：
提交后：
然后执行rebase发生冲突：
分支树为（此时分支为(no branch, rebasing dev)）：
打开冲突文件，冲突部分是以 <<<<<<<<<< ============= >>>>>>>>>>标识，将此部分代码进行处理，处理后的文件为：
执行add和rebase --continue
rebase结束，分支树为：
提交远程后，最终分支树如下：
（3）git3的index文件如下：
将index文件中的第一行修改为“create by git1 modifed in another place”，提交。
从远程拉取最新文件，执行rebase
最终结果如下：
（4）git1创建了一个index2.html文件，提交后push，远程拒绝push，原因是本地不是最新版本，需要更新后提交，拉取最新文件。
git1执行merge操作，最终分支树如下：
总结修改同文件不同处，rebase和merge合并不会冲突修改同文件同一处，合并会冲突，解决方式：rebase，解决冲突，执行add+rebase continue；merge，解决冲突，重新提交
