实际上，为了合并不同分支的代码，git merge并不是唯一的方法。git rebase同样可以达到合并的目的。那么，这两个命令的差别是什么呢？用文字描述可能会比较复杂，我们直接来看例子。

合并分支的过程

为了演示这个过程，我们新建一个空目录merge-code，然后依次完成下面的动作：

• 首先，创建个文件a@master.txt；
• 其次，提交到master：

git add .
git commit -m "Add a@master.txt"

这时，执行git log就会看到这样的结果：

或者，我们也可以执行git log --oneline查看提交信息摘要：

• 第三，新建并切换到一个新分支feature：git checkout -b feature；
• 第四，切换回master，新建一个文件b@master.txt并提交：

git checkout master
touch b@master.txt
git add .
git commit -m "Add b@master.txt"

• 第五，切换到feature分支，在这里，我们新建一个d@feature.txt：

git checkout feature
touch d@feature.txt
git add .
git commit -m "Add d@feature.txt"

• 第六，再创建并提交一个e@feature.txt：

git checkout feature
touch e@feature.txt
git add .
git commit -m "Add e@feature.txt"

• 第七，切换回master，这时merge-code目录中，应该还没有刚才创建的c@feature.txt和d@feature.txt，

• 第八，我们执行git merge feature把feature分支合并进来；

• 第九，执行git log --oneline --graph就会看到这样的结果：

其中，红色的线条表示master分支，绿色的线条表示feature分支。分支上的*表示我们完成的动作。这样我们上面的整个过程就看的很清楚了。

但有时，我们创建分支仅仅是为了不影响master，并没有必要在master的提交记录上看到这个创建分支的过程，因为分支的创建有可能会很频繁。这时，我们就可以使用git rebase命令。

通过rebase简化提交记录

为了了解rebase的用法，在master分支，我们先执行git reset --hard 12beaa3恢复到创建b@master.txt。然后，切换到feature分支。此时，master分支上有a@master.txt和b@master.txt，而feature分支上有d@feature.txt和e@feature.txt。

接下来，为了把feature分支上的提交记录合并到master，让这些行为看上去就像是在master分支上发生的，我们可以先在feature分支执行git rebase master，就会看到这样的结果：

图中，replay your work on top of it中的it，指的就是rebase后面的master。git会把我们在当前分支上的操作，“重放”到master当前的最新一次提交之后。对于我们的例子来说，也就是创建了b@master.txt之后。

现在，回到master分支，当我们再把feature合并进来之后，执行git log --oneline --graph，就会看到master上的提交日志就变成了这样：

也就是说，我们在这两个分支上进行的操作，从提交日志上已经看不出来了。master上的提交记录完全变成了一个序列化执行的日志。

Conclusion

以上，就是这个系列的内容。掌握了这些和git相关的用法之后，应该就足够应付日常的源代码管理工作了。并且，我们想再去深入了解git相关的特性时，也会变得更有重点。总之，git现在对我们来说，已经不是个问题了 :)

Discuss It

参与视频讨论