git rebase -i_git rebase -i改变生活的魔力

git rebase -i

软件开发混乱。 如此多的错误转弯，拼写错误得到纠正，快速的hack和错误纠正可以在以后发现的过程中发现一次又一次的错误。 使用版本控制，您可以清晰地记录在创建“完美”最终产品（准备好向上游提交的补丁）的过程中进行的每一次错误操作和更正的原始记录。 就像电影的票房一样，它们有些尴尬，有时还很有趣。

如果可以使用版本控制定期将您的工作保存在航路点，然后准备好要提交以供审阅的东西，则可以隐藏所有这些私人起草工作，而只需提交一份完整的补丁？ 认识git rebase -i ，这是重写历史记录的完美方法，使每个人都认为您是第一次生成完美的代码！

git rebase做什么？

如果您不熟悉Git的复杂性，这里是简要概述。 在幕后，Git将项目的不同版本与唯一标识符相关联，该唯一标识符由父节点唯一标识符的散列以及新版本与其父节点之间的差异组成。 这会创建一棵修订树，每个签出项目的人都会得到自己的副本。 不同的人可以在不同的方向进行项目，每个方向都可能从不同的分支点开始。

^{左侧“原始”存储库中的master分支，右侧是您的个人副本上的private分支。}

git merge ，另一个是使用git rebase 。 它们以不同的方式工作。

当您使用git merge时 ，将在master分支上创建一个新提交，其中包括来自原始位置的所有更改以及所有本地更改。 如果存在任何冲突（例如，如果其他人更改了您也在使用的文件），则将标记这些冲突，并且您有机会在将该合并提交提交到本地存储库之前解决冲突。 当您将更改推回父存储库时，所有本地工作将显示为Git存储库其他用户的分支。

但是git rebase的工作方式有所不同。 它回滚您的提交，并从master分支的顶端再次重放这些提交。 这导致两个主要变化。 首先，由于您的提交现在正在分支到另一个父节点，因此将重新计算其哈希值，并且克隆您的存储库的任何人现在都可能拥有该存储库的损坏副本。 其次，您没有合并提交，因此在将更改重播到master分支上时会识别出任何合并冲突，因此您需要先进行修复，然后再进行基础调整。 现在，当您进行更改时，您的工作不会出现在分支上，并且看起来您是从对主分支的最新提交中写入所有更改的。

^{合并提交（左）保留历史记录，而合并（右）则重写历史记录。}

但是，这两个选项都有缺点：在准备共享代码之前，每个人都可以在本地解决问题时看到所有涂鸦和编辑内容。 这是git rebase的--interactive （或简称-i ）标志出现在图片中的地方。

引入git rebase -i

git rebase的最大优点是它可以重写历史记录。 但是，为什么只假装您后来分支了呢？ 有一种更进一步的方法可以重写您如何准备就绪的代码： git rebase -i ，交互式git rebase 。

此功能是Git中的“魔术时光机”功能。 该标志允许您在进行基础更改时对修订历史进行复杂的更改。 您可以隐藏自己的错误！ 将许多小的更改合并到一个原始功能补丁中！ 重新排列版本历史记录中的内容！

当您运行git rebase -i时 ，您将获得一个编辑器会话，其中列出了所有正在被重新构建的提交以及可以对其执行的操作的多个选项。 默认选择是pick 。

• Pick会在您的历史记录中保留提交。
• Reword允许您更改提交消息，也许可以解决错字或添加其他注释。
• 编辑允许您在重播分支的过程中对提交进行更改。
• Squash将多个提交合并为一个。
• 您可以通过在文件中移动来重新排列提交。

完成后，只需保存最终结果，即可执行重新设置基准。 在您选择修改提交的每个阶段（使用reword ， edit ， squash或发生冲突时），变基都会停止并允许您在继续之前进行适当的更改。

上面的示例导致“单一代码错误修复”和“在各处集成新标头”被合并为一个提交，而“文档网站的新标头”和“ D'oh-错字。已固定”被合并为另一个提交。 就像魔术一样，进入其他提交的工作仍在您的分支上，但是相关的提交已从您的历史中消失了！

这使得使用git send-email或通过使用新整理的补丁集针对父存储库创建拉请求轻松地向上游项目提交干净补丁。 这具有许多优点，包括使您的代码更易于查看，更易于接受和更易于合并。

翻译自: https://opensource.com/article/20/4/git-rebase-i

git rebase -i