git merge 和 git rebase 都是用于合并分支，但二者是存在区别的。

在使用时，记住以下两点：

  1. 当你从 remote 去 pull 的时候，永远使用 rebase（除了一个例外）
  2. 当你完成了一个功能（假定你是单独开本地分支去做的）后打算合并到主干分支的时候，永远使用 merge

一、merge

　　 marge 特点：自动创建一个新的commit
　　如果合并的时候遇到冲突，仅需要修改后重新commit
　　优点：记录了真实的commit情况，包括每个分支的详情
　　缺点：因为每次merge会自动产生一个merge commit，所以在使用一些git 的GUI tools，特别是commit比较频繁时，看到分支很杂乱

二、rebase

　　rebase 特点：会合并之前的commit历史
　　优点：得到更简洁的项目历史，去掉了merge commit
　　缺点：如果合并出现代码问题不容易定位，因为re-write了history　　合并时如果出现冲突需要按照如下步骤解决
    • 修改冲突部分
    • git add
    • git rebase --cotinue
    • （如果第三步无效可以执行 git rebase --skip）
　　不要在git add 之后习惯性的执行 git commit命令　　

　　The Golden Rule of Rebasing：never use it on public branches(不要在公共分支上使用)

三、总结

    • merge 是一个合并操作，会将两个分支的修改合并在一起，默认操作的情况下会提交合并中修改的内容
    • merge 将分支合并，会自动创建一个新的 commit，会引入一个外来的合并提交
    • merge 的提交历史忠实地记录了实际发生过什么，关注点在真实的提交历史上面
    • rebase 并没有进行合并操作，只是提取了当前分支的修改，将其复制在了目标分支的最新提交后面
    • rebase 是变基操作，能有效的将所有 master 上新的提交并入过来
    • rebase 的提交历史反映了项目过程中发生了什么，关注点在开发过程上面

四、建议操作方式

  1. 完成功能分支之后先不 merge，而是回到主干分支去 git pull --rebase
  2. 如果主干有更新，rebase 更新的内容到功能分支来预检一下，看看在加入了最近别人的改动之后我的功能是否依然 OK（在这个过程中可能会有冲突处理，别怪我没提醒哦）
  3. 一切就绪之后再次 git fetch 主干看看有没有变动（因为在第二步的进行期间没准又有人 push 了新的变化），有的话重复第二步，没有则——
  4. 合并功能分支到主干然后 push，完成。