Git 2.22：保留拓扑和交互式 Rebase

git Rebase| 2019-07-22

在Git 发布的最新版本 Git 2.22中，最重要的新功能是，它支持”变基“（rebase）复杂的分支拓扑，例如，对于那些合并后不会扁平化分支拓扑的合并，也允许使用交互式的“变基”功能。

在基础分支（如 master 分支）发生变更后再合并其他功能分支时，”变基“提交是保持 Git 历史记录线性的好方法。在这种情况下，为了保证这两个分支不丢失任何变更，Git 的标准做法是，将 master 合并到功能分支上，然后再尝试将功能分支合回 master。这期间，我们不仅可以解决 Git 无法自己解决的任何合并冲突，而且 Git 还将创建一个 master 分支的提交拓扑，该拓扑在需要三向“合并”时，可以显式地展示合并操作。

与“合并”操作相反，在没有任何冲突的情况下，在有分叉的 master 分支进行“变基”提交时，Git 只会假设你是在当前的 master 结点上开始处理导致该提交的分支。在这种情况下，master 分支的历史记录将不会显示创建了新分支并又将其合回 master 分支的事实。这样整个历史记录看起来是线性的。

如果功能分支想要“变基”自己将会生成一个包括子分支和合并在内的复杂拓扑，在这种情况下，后一种方法就不太适用了。为了解决这个问题，现在可以将新的–rebase-merges 选项用在“新基”上重放一组提交，并能保持“变基”分支的拓扑。此外，它还包括交互式“变基”功能，如重命名、压缩、重新排序等。从概念上讲，使用交互功能进行 rebase-merges（几乎）等同于先执行 preserve-merges，再执行 rebase -i。事实上，在 Git 2.22 中， preserve-merges 选项已弃用，取而代之的是 rebase-merges。具体的可以查看Stack Overflow. 上关于 rebase-merge背后算法的深入讨论。

在 Git2.22 中，对 rebase-merges 的支持并不是唯一的变化，它还包括很多其他新特性和错误修复。在此，我们重点罗列如下几条：

当需要的粒度比用户允许的更大时，可以为作者和提交者的姓名和电子邮件定义新的配置变量。
可以通过执行 git branch –show-current 来获取当前分支的名称。
如果从一个分支中签出了一个目录，并且当前的目录树中包含了新的跟踪文件，那么在默认情况下，git 将不会关联后者，因此你最终将得到来自已签出分支和当前分支的混合文件。现在，可以通过在 git checkout 上添加–no-overlay 选项，确保可以删除跟踪文件或根据需要进行重新创建。

Git 2.22 的变更内容比本文介绍的要多得多，因此，请阅读官方发布说明来了解完整的细节。