前2天群里发了张git历史图，如下：

根据提交历史，可以看出图中所有分支合并都采用merge的方式，具体merge是怎么操作的，可以阅读下边文章。

---

根据项目上的需求，如果要求git提交历史是比较简单的一条时间线，可以使用rebase的合并；如果没有这个要求，可以使用merge合并，其分支树是网状结构，但每个提交也都是比较明确清晰的。他们的区别，可参考git merge与 git rebase区别及实例：

• rebase合并：本质是先取消自己的提交，临时保存，然后把当前分支更新到最新的origin分支，最后应用自己的提交。
• merge合并：将两个分支进行合并提交。

 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，解决冲突，重新提交