Git merge && git rebase的用法
本文由 简悦 SimpRead 转码， 原文地址 www.cnblogs.com
Git merge 的用法：
git merge Dev // Dev 表示某分支，表示在当前分支合并 Dev 分支
git merge -m “Merge from Dev” Dev //-m 可以加上 merge 时要添加的描述性语句，如果出现冲突，那么先解决冲突，再将文件 git add，git commit，之后再 merge
Git rebase 的用法：
与 merge 的形式一样，git rebase dev，作用也一样是在当前分支合并 Dev 分支，如果 git rebase 遇到冲突，第一步当然是解决冲突，然后 git add，之后并不需要 git commit，
而是直接运行 git rebase –continue，这样 git 就会继续应用剩下的补丁了，// 假如你不想解决冲突且不再进行合并，那么可以使用 git rebase –abort
git merge 与 git rebase 的区别：
举例两个分支 Dev 和 master 刚开始处于同一起点，之后各自前进，Dev 是只有自己修改，但是 master 有其他人的修改，此时如果准备在 master 分支上将 Dev 分支合并，
使用 git merge 的结果像是一个新的合并的提交，而 git rebase 看起来则像没有经历过任何合并一样
下面是转载自 http://blog.csdn.net/wh_19910525/article/details/7554489 很不错的一篇博客
他们的 原理 如下：
假设你现在基于远程分支 “origin”，创建一个叫 “mywork” 的分支。
$ git checkout -b myworkorigin
假设远程分支 “origin” 已经有了 2 个提交，如图
现在我们在这个分支做一些修改，然后生成两个提交 (commit).
$ vi file.txt
$ git commit
$ vi otherfile.txt
$ git commit
…
但是与此同时，有些人也在 “origin” 分支上做了一些修改并且做了提交了. 这就意味着 “origin” 和 “mywork” 这两个分支各自 “前进” 了，它们之间 “分叉” 了。  取消掉，并且把它们临时 保存为补丁(patch)(这些补丁放到 “.git/rebase” 目录中), 然后把 “mywork” 分支更新 为最新的 “origin” 分支，最后把保存的这些补丁应用到 “mywork” 分支上。
当’mywork’分支更新之后，它会指向这些新创建的提交 (commit), 而那些老的提交会被丢弃。 如果运行垃圾收集命令 (pruning garbage collection), 这些被丢弃的提交就会删除. （请查看 git gc) . 在这种情况，Git 会停止 rebase 并会让你去解决 冲突；在解决完冲突后，用 “git-add” 命令去更新这些内容的索引 (index), 然后，你无需执行 git-commit, 只要执行:
$ git rebase –continue
这样 git 会继续应用 (apply) 余下的补丁。
在任何时候，你可以用 –abort 参数来终止 rebase 的行动，并且 “mywork” 分支会回到 rebase 开始前的状态。
$ git rebase –abort
三、git rebase 和 git merge 的区别
现在我们可以看一下用合并 (merge) 和用 rebase 所产生的历史的区别：
当我们使用 Git log 来参看 commit 时，其 commit 的顺序也有所不同。
假设 C3 提交于 9:00AM,C5 提交于 10:00AM,C4 提交于 11:00AM，C6 提交于 12:00AM,
对于使用 git merge 来合并所看到的 commit 的顺序（从新到旧）是：C7 ,C6,C4,C5,C3,C2,C1
对于使用 git rebase 来合并所看到的 commit 的顺序（从新到旧）是：C7 ,C6‘,C5’,C4,C3,C2,C1
因为 C6’提交只是 C6 提交的克隆，C5’提交只是 C5 提交的克隆，
从用户的角度看使用 git rebase 来合并后所看到的 commit 的顺序（从新到旧）是：C7 ,C6,C5,C4,C3,C2,C1
Git merge && git rebase的用法
