git rebase 和 git merge 总结

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

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

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

1、merge

　　  marge 特色：自动建立一个新的commit
　　若是合并的时候遇到冲突，仅须要修改后从新commit
　　优势：记录了真实的commit状况，包括每一个分支的详情
　　缺点：由于每次merge会自动产生一个merge commit，因此在使用一些git 的GUI tools，特别是commit比较频繁时，看到分支很杂乱

2、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(不要在公共分支上使用)

3、总结

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

4、建议操做方式

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