本章所介绍的工作流会产生多次合并提交，从而使得提交历史变得非常难以阅读。对此，另一种做法改用变基的方式将*版本库中的修改合并到本地修改中(即在执行 pull 命令时使用--rebase 参数)。

> git pull --rebase

通过对本地修改的变基，我们就可以再次提交*版本库 master 分支上的提交了。也就是说，变基创建的是一次新的提交，但它可以包含相同的修改内容。
在下图中，我们可以看到两段不同的提交历史，分别由合并操作和变基操作产生。

一眼看去，变基操作的那段历史记录因其没有多余分叉的线性结构而格外引人注目。但 这个优点会被该历史中提交的即时性所掩盖，在这种情况下，开发者就无法在其本地环境中 获取各个版本的详细信息了。因为在执行变基操作的过程中，总会有多个提交对象被复制。

因此，开发者们只能查看最后提交中的内容。另外，这些被复制的还都是未经测试的版本。
以图中的提交 F’为例。该提交是由提交 G 变基而来的。只要后者在被复制到提交 F’的过程中没有引发冲突，该提交就会被忽略。然而，我们也可以想象，版本上所造成的误差也有可能会导致它根本不能工作。

如果我们只需要知道谁做了这些提交，这一切都没有问题。但一旦我们想依靠这段话提交历史来解决什么问题，这些提交就会开始让人头痛了。
如果我们在工作中会大量使用变基操作，也可以通过以下设置将其配置成 pull 命令的默 认行为：

 > git config branch.master.rebase true

在这里， branch.master.rebase 参数决定了哪一个分支被启用为变基操作的默认分支。即 其分支名 ( master) 可以被替换成任何其他的分支名。

---

⏪ 温习回顾上一篇（点击跳转）： 《【Git教程】（十二）工作流之项目设置 — 何时使用工作流，工作流的结构，项目设置概述、执行过程及其实现 ~》

⏩ 继续阅读下一篇（点击跳转）： 《》