What 's the difference between 'git merge' and 'git rebase'?

当我们在使用git这样的版本控制系统来管理项目的源代码时，git merge和git rebase是两种常用的方法来整合不同分支的改动。它们的主要目的都是将两个分支的变更合并到一起，但它们各自的工作方式及其对提交历史的影响却有所不同。

git merge

git merge是一种非常直接的合并方式，它会将两个分支的最新快照（commit）以及两个分支的共同祖先取出，然后尝试自动合并这些改动。如果不同分支在相同的文件的相同部分都做了修改，那么就会产生冲突，需要手动解决。

合并完成后，git会创建一个新的“合并提交”（merge commit），这个提交会有两个父节点，分别表示合并前的两个分支的状态。这种方式保留了完整的、非线性的项目历史，从而可以清楚地看到项目是如何随着时间发展而进化的，包括所有分支和合并点。

git rebase

git rebase的主要思想是取出一系列的提交（commits），"复制"它们，然后在另一个地方逐个"粘贴"（重新应用）。这个过程的目的是使得一个分支的改动可以像从未分叉一样直接在另一个分支上展开。

具体来说，假设你正在一个特性分支上开发，这个分支从master分支分出去了。随着你在特性分支上的开发，master分支也可能有了新的提交。在这种情况下，你可以使用git rebase将你的特性分支上的改动重新应用到master分支的当前端点（HEAD）。这样，你的特性分支的提交就会排在master的提交之后，从而得到一个线性的历史。

对比

• 历史清晰度：git merge保留了一个真实的、非线性的历史，你可以看到项目的所有分支及其合并点。而git rebase则创建了一个更干净、线性的历史。
• 冲突处理：在git rebase中，冲突可能会在rebase过程中的每一次commit应用时发生，需要逐个解决。而在git merge中，冲突只在最后的合并时一次性处理。
• 推荐使用场景：git merge通常用于合并公共或共享分支（例如，将完成的特性分支合并回master或develop分支）。git rebase通常用于个人的开发过程，如将最新的master分支变更合并到你的特性分支中，以避免将来合并master时的复杂性。

实例

假设我正在开发一个新功能，在feature分支上工作。与此同时，我的同事在master分支上推进了一些改动。为了保持我的分支更新，我可以选择：

1. 使用git merge：

   bash
   git checkout feature
   git merge master

   这样会在我的feature分支上创建一个新的合并提交。

2. 使用git rebase：

   bash
   git checkout feature
   git rebase master

   这会将我的feature分支上的所有改动重新应用在master分支的最新改动之后。

总的来说，选择哪种方式取决于你想要的项目历史的样子，以及你个人或团队的工作流程。