git互动式恢复指南，并有实践示例

Git交互式变基：提升开发效率的利器

在现代开发者的工具箱中，Git版本控制已成为标配。commit、push和pull等命令早已成为肌肉记忆。然而，相对而言，很少有开发者了解Git中“更高级”的功能，以及这些功能的巨大价值！本文将探讨Git中最强大的工具之一——“交互式变基”。

核心要点

• 交互式变基是一个强大的Git工具，允许开发者创建结构良好的提交历史，使项目的代码库更易读，更容易理解。
• 交互式变基可用于编辑旧的提交信息、删除提交、合并多个提交、重新排序提交、修复旧的提交以及拆分/重新打开旧的提交以进行编辑。
• 重要的是，不要在已与远程仓库中的同事共享的提交上使用交互式变基，因为它会重写历史。相反，应该在将本地提交合并到团队分支之前使用它来清理本地提交。
• 交互式变基操作的基本机制包括：识别要操作的提交历史部分，使用git rebase -i命令启动会话，然后在打开的编辑器窗口中指定所需的操作。
• 交互式变基可以用来编辑旧的提交信息，删除不需要的提交，并将多个提交合并成一个，从而优化和清理提交历史。

为什么交互式变基应该成为每个开发者工具箱的一部分

简而言之，毫不夸张地说，交互式变基可以通过允许您在项目中创建干净且结构良好的提交历史来帮助您成为更好的开发者。

为什么结构良好的提交历史很重要？想象一下相反的情况：难以阅读的提交历史，您不知道您的同事最近的更改实际上做了什么。这样的项目中会开始出现越来越多的“黑暗角落”，您只了解自己参与的那一小部分。

将其与干净且结构良好的提交历史进行对比：它有助于使项目的代码库更易读和更容易理解。这是健康、持久项目的必要组成部分！

交互式变基能为您做什么

交互式变基可帮助您优化和清理提交历史。它涵盖许多不同的用例，其中一些允许您执行以下操作：

• 编辑旧的提交信息
• 删除提交
• 合并/组合多个提交
• 重新排序提交
• 修复旧的提交
• 拆分/重新打开旧的提交以进行编辑

何时使用交互式变基（以及何时不使用！）

与其他一些Git工具一样，交互式变基“重写历史”。这意味着，当您使用交互式变基操作一系列提交时，提交历史的这部分将被重写：提交的SHA-1哈希将发生更改。可以这样说，它们是全新的提交对象。

这一事实需要遵守一个简单但重要的规则：不要在您已与远程存储库中的同事共享的提交上使用交互式变基（或其他重写历史的工具）。相反，请使用它来清理您自己的本地提交——例如，在您自己的某个功能分支中——然后再将它们合并到团队分支中。

交互式变基操作的基本机制

尽管交互式变基可以用于许多不同的事情，但其基本工作流程始终相同。一旦您牢固地理解了这个基本机制，交互式变基就会失去其“复杂神秘”的氛围，并成为您工具箱中一个有价值且易于使用的工具。

步骤 1：您应该在哪里启动会话？

您需要回答的第一个问题是：“我想操作提交历史的哪一部分？”这告诉您应该在哪里启动交互式变基会话。让我们举一个实际的例子，假设我们要编辑旧的提交信息（这正是我们稍后在实践中要做的）。

我们的起始情况如下图所示，我们通过交互式变基编辑旧的提交信息。

为了能够更改C2中的提交信息，我们必须在其父提交处（或者更早，如果您愿意）启动交互式变基会话。在这个例子中，我们将使用C1作为交互式变基会话的起点。

步骤 2：启动实际会话！

启动实际会话非常简单：

<code>$ git rebase -i HEAD~3</code>

我们使用带有-i标志的git rebase命令（表示我们确实希望它是“交互式的”)，并提供基本提交（我们在上面的第一步中想出的）。在这个例子中，我使用了HEAD~3来指定“落后于HEAD提交3个提交”的提交。或者，我也可以提供一个特定的SHA-1哈希。

步骤 3：告诉Git您想做什么

启动交互式变基会话后，您将看到一个编辑器窗口，其中Git列出一系列提交——从最新的提交一直到（但不包括）您在步骤1中选择的作为基本提交的提交。

在此步骤中，需要注意两点：

1. 提交按反向顺序列出！我们期望出现在顶部的最新提交将出现在列表的底部。别担心：您的Git存储库完好无损！? 请记住，我们正在执行交互式变基操作，这需要Git在操作结束时从旧到新重新应用提交。
2. 不要在此编辑器窗口中进行实际更改！尽管您可能很想直接在此编辑器窗口中更改提交信息（毕竟，这正是我们想要做的……），但您必须耐心等待。在这里，我们只是告诉Git我们想做什么——而不是进行实际更改。我将很快在实践中演示这一点！

有了这个理论概述，让我们一起深入研究一些实际案例！

编辑旧的提交信息

交互式变基最流行的用例之一是，您可以在事后编辑旧的提交信息。您可能知道git commit --amend也允许您更改提交的信息——但这仅适用于最新的提交。对于任何比这更旧的提交，我们都必须使用交互式变基！

让我们来看一个具体的场景。下面是需要更正的错误提交信息的图像。

注意：为了更好地概述和更清晰的可视化，我在一些屏幕截图中使用了Tower Git桌面客户端。您不需要Tower就可以按照本教程进行操作。

对于我们的示例，假设我们要编辑当前标题为“Optimize markup structure in index…”的提交的消息。

我们的第一步是确定此交互式变基会话的基本提交。由于我们必须（至少）返回到我们的“坏苹果”提交的父提交，因此我们以HEAD~3（落后于HEAD提交三个提交，即标题为“Change headlines …”的提交）作为会话的起点：

<code>$ git rebase -i HEAD~3</code>

执行此命令后，您最喜欢的编辑器将打开并显示您刚刚选择的提交列表（通过提供基本提交）。

提醒一下：虽然您可能很想这样做，但我们在这里不会更改提交信息。我们只用“操作关键字”标记相应的行。在我们的例子中，我们要改写提交（这意味着我们想更改提交信息，但保留提交的其余部分）。

实际上，所有可用的操作关键字都在此窗口的底部有说明——因此无需记住任何内容！

一旦您用首选操作关键字替换了标准的pick关键字（这意味着“按原样接受提交”），您只需保存并关闭窗口即可。

这样做之后，将打开一个新的编辑器窗口，其中包含当前的提交信息。最后，我们可以做我们一开始就打算做的事情：编辑这个旧提交的消息！

在我们进行更改并保存并关闭编辑器窗口后，交互式变基会话就完成了——我们的提交信息已更新！?

删除不需要的提交

交互式变基还允许您从不需要（或不想要）的历史记录中删除旧的提交。想象一下，您不小心在最近的提交中包含了个人密码：在大多数情况下，此类敏感信息不应包含在代码库中。

还要记住，简单地删除信息并再次提交并不能真正解决您的问题：这意味着密码仍然以旧提交的形式保存在存储库中。您真正想要的是从存储库中完全干净地删除此数据！

让我们首先确定交互式变基会话的基本提交。由于我们需要至少从错误提交的父提交开始，因此我们使用“Optimize markup structure…”提交作为我们的基础：

<code>$ git rebase -i HEAD~3</code>

请注意，这次我在git rebase -i命令中使用了具体的SHA-1哈希。当然，除了提交哈希之外，我还可以使用HEAD~2来处理该提交。

执行此命令后，我们将再次看到一个提交列表。

这次，我们使用drop操作关键字来摆脱不需要的提交。或者，在这种特殊情况下，我们也可以简单地从编辑器中删除整行。如果在保存和关闭窗口时不再存在一行（代表一个提交），Git将删除相应的提交。

无论您选择哪种方式，在保存并关闭编辑器窗口后，提交将从您的存储库历史记录中删除！

将多个提交合并为一个

交互式变基的另一个用例是当您想将多个单独的提交合并为一个时。在我们深入探讨如何工作之前，让我们花几分钟时间讨论何时或为什么这可能很有价值。

一般来说，使提交“更大”（通过将多个提交合并为一个）在大多数情况下不是一个好策略。一般的经验法则是尽可能使提交保持较小，因为“较小”意味着“更容易阅读和理解”。但是，在某些情况下，这仍然是有意义的。以下列举两个例子：

• 想象一下，您注意到旧提交存在问题。然后，您可以继续生成一个新的提交来修复该问题。在这种情况下，将这些提交合并为一个提交很有意义：毕竟，较新的提交只是为了修复本来不应该存在的问题的“权宜之计”。通过组合这些提交，看起来好像根本没有问题！
• 另一个例子是当您注意到您做得有点太细致了。进行小的提交很好，但是用许多不必要的小提交来填充您的提交历史将意味着超过了目标。

在这两个例子中的基本原理都是相同的：通过组合本来应该是一个提交的两个（或多个）提交，您正在创建更干净、更易读的提交历史！

让我们一起完成一个实际示例，并以以下图片所示的情况作为我们的起始情况。

假设从语义上讲，将这两个提交合并为一个提交更有意义。使用交互式变基的squash工具，我们可以做到这一点：

<code>$ git rebase -i HEAD~3</code>

到目前为止，您已经习惯了接下来会发生什么：一个编辑器窗口将打开，其中包含提交列表。

我已经提到过，在这种情况下我们将使用squash操作关键字。关于squash如何工作，有一件重要的事情要知道：您用关键字标记的行将与正上方的行合并！这解释了为什么我在我们的示例中用squash关键字标记了第2行。

保存并关闭此窗口后，将打开一个新窗口。这是因为，通过组合多个提交，我们当然会创建一个新的提交。而这个提交也需要提交信息，就像任何其他提交一样！

您在上面的屏幕截图中看到的是Git为我们准备的内容：它将相应原始提交的提交信息与一些注释组合在一起。您可以随意删除旧消息并重新开始——或者保留它们并添加更多信息。

保存并关闭此编辑器窗口后，我们可以自豪地说：以前是两个单独的提交，现在是一个提交了！

利用交互式变基的强大功能

我希望您同意Git的交互式变基工具非常有价值！作为开发者，我们必须努力争取干净清晰的提交历史。这是保持代码库健康且易于理解（对于您的队友和您自己，在一段时间过去之后）的关键因素。

如果您想了解更多信息，我强烈推荐“Git急救包”。这是一个（免费的）简短视频合集，向您展示如何清理和撤消Git中的错误。

玩得开心！

Git交互式变基常见问题解答 (FAQ)

Git变基和Git合并有什么区别？

Git变基和Git合并是将一个分支的更改集成到另一个分支的两种不同方法。Git合并是一种直接组合来自两个不同分支的代码的方法。它在历史记录中创建一个新的提交，保留提交的时间顺序。另一方面，Git变基是一种将一系列提交移动或组合到新的基本提交的方法。这就像说“我想在我的更改的基础上添加其他人的工作”。换句话说，它允许您将当前分支的更改放置在另一个分支的顶部。

如何撤消Git变基？

如果您想撤消Git变基，可以使用命令git reflog来查找要返回到的提交，然后使用命令git reset --hard HEAD@{number}。git reflog命令显示对HEAD所做的每个更改的列表，git reset命令允许您将当前HEAD设置为指定状态。

Git交互式变基的目的是什么？

Git交互式变基允许您以多种方式更改提交，例如编辑、删除和压缩。您不仅可以更改提交信息，还可以更改实际代码（如果您犯了错误）。这是一个强大的工具，可以让您完全控制项目的提交历史。

如何使用Git交互式变基压缩提交？

压缩是将多个提交合并为一个提交的行为。在Git中，您可以使用git rebase -i命令后跟要压缩的提交哈希来压缩提交。在打开的文本编辑器中，您可以通过将pick替换为squash或s来标记要压缩的提交。

使用Git交互式变基的风险是什么？

虽然Git交互式变基是一个强大的工具，但如果使用不当，它可能是危险的。它会重写提交历史，如果您正在处理其他人也在处理的公共分支，这可能会造成问题。建议在尚未推送的本地分支上使用它。

如何在Git变基期间解决冲突？

在变基过程中，可能会发生冲突。Git将暂停并允许您在继续之前解决这些冲突。您可以通过编辑文件来修复冲突的更改，然后使用git add添加已解决的文件来解决冲突。解决所有冲突后，您可以使用git rebase --continue继续变基。

我可以使用Git交互式变基来拆分提交吗？

是的，您可以使用Git交互式变基将一个提交拆分为较小的提交。如果您在一个提交中进行了多次更改，但后来决定它们应该成为单独的提交，这将非常有用。

如何使用Git交互式变基编辑提交信息？

您可以在交互式变基期间编辑提交信息。在提交列表中，将pick替换为reword或r，以标记要编辑的提交。继续时，Git将为每个标记为reword的提交打开一个文本编辑器，允许您更改提交信息。

Git变基和Git拉取有什么区别？

Git pull是一个从远程存储库获取更改并将它们合并到当前分支的命令。另一方面，Git rebase是一个将一系列提交移动或组合到新的基本提交的命令。虽然这两个命令都用于集成更改，但它们以不同的方式进行。

我可以使用Git交互式变基来更改提交的顺序吗？

是的，您可以使用Git交互式变基来更改提交的顺序。在提交列表中，您可以简单地更改行的顺序来更改提交的顺序。如果您想使您的提交历史更合乎逻辑或更清晰，这将非常有用。

以上是git互动式恢复指南，并有实践示例的详细内容。更多信息请关注PHP中文网其他相关文章！