Git命令meger和rebase命令的用法和区别

一、简介

Git 整合分支一般有 git merge 和 git rebase 两种。rebase 通常就是我们所说的变基。
git merge 是最方便的合并操作，也会保留真实完整的 commit 信息。但是也会导致一个问题，就是会使得提交历史发生很多分叉。这样如果提交变得多了，分支分叉就会导致提交历史历史线变得十分混乱。因此，就有 rebase 操作，可以使得分支的线变得十分干净。
简单来说，使用 rebase 命令将提交到某一分支上的所有修改都移至另一分支上。这样做的目的是为了确保在向远程分支推送时能保持提交历史的整洁。

二、Git Merge

在IDEA中显示的Git提交记录：

如图所示：
在merster分支提交了两次记录A和B，然后基于master分支创建dev新分支，并在dev分支提交了两次记录C和D，此时在master分支也有两次提交记录E和F，最后在master分支使用git merge dev命令将dev分支的代码合并到master分支上。

使用git log --graph --oneline命令可以查看合并日志：

三、Git Rebase

如图所示：
现在同样有主分支 master 与 开发分支 dev，需要将 dev 合并到 master。
master分支上提交（commit）了C2 和C3记录,并且已经推送（push）到了远程仓库。
dev分支上提交了C4和C5记录，但是还未push到远程仓库。

注意：如果提交存在于你的仓库之外，而别人可能基于这些提交进行开发，那么不要执行变基。

然后使用rebase命令进行合并：切换到dev分支进行变基，将master分支上的提交记录在dev分支重演一遍，需要解决冲突:

然后切换到master分支进行合并：git merge dev：

将master分支push到远程仓库：

切换到dev分支，将dev分支代码也push到远程仓库。

三、总结

无论是 rebase 还是 merge ，整合的最终结果所指向的快照始终是一样的，只不过提交的历史不同罢了。变基是将一系列提交按照原有次序依次应用到另一分支上，而合并是把最终结果合在一起。

变基 vs. 合并
至此，你已在实战中学习了变基和合并的用法，你一定会想问，到底哪种方式更好。 在回答这个问题之前，让我们退后一步，想讨论一下提交历史到底意味着什么。
有一种观点认为，仓库的提交历史即是 记录实际发生过什么。 它是针对历史的文档，本身就有价值，不能乱改。 从这个角度看来，改变提交历史是一种亵渎，你使用 谎言 掩盖了实际发生过的事情。 如果由合并产生的提交历史是一团糟怎么办？ 既然事实就是如此，那么这些痕迹就应该被保留下来，让后人能够查阅。
另一种观点则正好相反，他们认为提交历史是 项目过程中发生的事。 没人会出版一本书的第一版草稿，软件维护手册也是需要反复修订才能方便使用。 持这一观点的人会使用 rebase 及 filter-branch 等工具来编写故事，怎么方便后来的读者就怎么写。
现在，让我们回到之前的问题上来，到底合并还是变基好？希望你能明白，这并没有一个简单的答案。 Git 是一个非常强大的工具，它允许你对提交历史做许多事情，但每个团队、每个项目对此的需求并不相同。 既然你已经分别学习了两者的用法，相信你能够根据实际情况作出明智的选择。
总的原则是，只对尚未推送或分享给别人的本地修改执行变基操作清理历史， 从不对已推送至别处的提交执行变基操作，这样，你才能享受到两种方式带来的便利。

文章参考

git-rebase - Reapply commits on top of another base tip
3.6 Git 分支 - 变基
一文搞懂 git rebase
百度、阿里、腾讯之类的大公司用 Git 吗？他们如何管理源代码？
分支的整合：git rebase Or git merge
git merge 和 git rebase的区别