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 的变更内容比本文介绍的要多得多,因此,请阅读官方发布说明来了解完整的细节。

余下全文(1/3)
分享这篇文章:

请关注我们:

发表评论

电子邮件地址不会被公开。 必填项已用*标注