Java中的合并与重组（上）

通过优锐课核心java学习笔记中，我们可以看到，码了很多专业的相关知识，分享给大家参考学习。

虽然在Git中合并和重组是相似的，但它们具有两种不同的功能。要保持自己的历史记录整洁或完整，这是你应该知道的。

git rebase命令以其神奇的Git伏都教徒而闻名，初学者应该远离它，但是当谨慎使用时，它实际上可以使开发团队的生活变得更加轻松。在本文中，我们将git rebase与相关的git merge命令进行比较，并确定所有将rebase纳入典型Git工作流程的潜在机会。

概念概述

了解git rebase的第一件事是它解决了与git merge相同的问题。这两个命令都旨在将更改从一个分支集成到另一个分支，它们只是以非常不同的方式来进行更改。

考虑当你在专用分支中开始使用新功能时发生了什么，然后另一个团队成员使用新的提交更新主分支。这导致了分叉的历史，对于使用Git作为协作工具的任何人都应该熟悉。

现在，假设master中的新提交与你正在使用的功能有关。要将新提交合并到功能分支中，你有两种选择：合并或重新设置基础。

合并选项

最简单的方法是使用以下方法将主分支合并到功能分支中：

git checkout feature

git merge master

或者，你可以将其浓缩为单线：

git merge master feature

这会在功能分支中创建一个新的“合并提交”，将两个分支的历史联系在一起，从而为你提供一个如下所示的分支结构：

合并很好，因为它是一种无损操作。现有分支不会以任何方式更改。这避免了重新设置基准的所有潜在陷阱（如下所述）。

另一方面，这也意味着每次需要合并上游更改时，功能分支将具有无关的合并提交。如果master非常活跃，这可能会污染功能分支的历史记录。虽然可以通过高级git log选项缓解此问题，但其他开发人员可能很难理解该项目的历史记录。

变基选项

作为合并的替代方法，你可以使用以下命令将功能分支基于主分支：

git checkout feature

git rebase master

这会将整个功能分支移到主分支的顶端，从而有效地将所有新提交合并到主分支中。但是，与其使用合并提交，不如通过为原始分支中的每个提交创建全新的提交来重新编制基础项目历史记录。

变基的主要好处是你可以获得更清晰的项目历史记录。首先，它消除了git merge所需的不必要的合并提交。其次，如你在上图中所看到的那样，重新定基也可以实现完美的线性项目历史记录-你可以一直沿功能的顶端一直到项目开始，而无需任何分叉。使用git log，git bisect和gitk等命令可以更轻松地浏览项目。

但是，对于这个原始提交历史，有两个折衷：安全性和可追溯性。如果你不遵循“变基础的黄金法则”，那么重写项目历史记录可能会对你的协作工作流程造成灾难性的影响。而且，更不重要的是，重新定基会丢失合并提交所提供的上下文-你看不到何时将上游更改合并到功能中。

互动基础

交互式重定基础使你有机会在提交移至新分支时更改提交。由于它可以完全控制分支的提交历史，因此它甚至比自动重新设置功能更强大。通常，这用于在将功能分支合并到master之前清理混乱的历史记录。

要开始交互式重新基准化会话，请将i选项传递给git rebase命令：

git checkout feature

git rebase -i master

这将打开一个文本编辑器，列出所有将要移动的提交：

pick 33d5b7a Message for commit #1

pick 9480b3d Message for commit #2

pick 5c67e61 Message for commit #3

此清单准确定义了执行变基后分支的外观。通过更改选择命令和/或重新排列条目的顺序，你可以使分支的历史记录看起来像你想要的任何东西。例如，如果第二个提交解决了第一个提交中的一个小问题，则可以使用fixup命令将它们压缩为一个提交：

pick 33d5b7a Message for commit #1

fixup 9480b3d Message for commit #2

pick 5c67e61 Message for commit #3

当你保存并关闭文件时，Git将根据你的指示执行变基，从而产生类似于以下内容的项目历史记录：

消除这种微不足道的提交，可以使你功能的历史记录更容易理解。这是git merge根本无法做到的事情。

扎根的黄金法则

一旦了解了什么是基础，最重要的事情就是什么时候不做基础。 git rebase的黄金法则是永远不要在公共分支上使用它。

例如，考虑如果你将母版重新基于功能分支会发生什么情况：

rebase将master中的所有提交移动到功能的尖端。问题是这仅发生在你的存储库中。所有其他开发人员仍在使用原始的master。由于重新定基会带来全新的承诺，因此Git会认为你的分支机构的历史与其他人有所不同。

同步两个主分支的唯一方法是将它们重新合并在一起，从而产生一个额外的合并提交和两组包含相同更改的提交（原始更改和来自你的基于重新定义分支的更改）。不用说，这是一个非常令人困惑的情况。

因此，在运行git rebase之前，请始终问自己：``还有其他人在看这个分支吗？'' 如果答案是肯定的，请放开键盘，然后开始考虑一种无损方式进行更改的方法（例如git revert命令）。否则，你可以随意重写历史记录。