git 修复中间版本_如何修复git中的错误并且不留痕迹

git 修复中间版本

You finally found it: a bug in an old commit! And luckily, you already have a solution in mind. So you just need to fix your mistakes in a new commit and everything is fine, right?

您终于找到了它：旧提交中的错误！ 幸运的是，您已经有了一个解决方案。 因此，您只需要在新提交中更正错误，一切都很好，对吧？

Photo by the author.

图片由作者提供。

Well, not really. If you follow this strategy for a while, your commit history will be littered with these little “band-aid” commits. They don’t have any semantic meaning — and they shouldn’t be there in the first place! When someone else (or you, after some time) takes a look at the commit history, they will see the flawed original commit, scratch their heads, and only later, sprinkled somewhere in the commit log, find a commit that corrects the original commit’s mistakes.

好吧，不是真的。 如果按照这个战略的同时，你的提交历史将与这些小“创可贴”被提交散落。 它们没有任何语义上的意义-而且它们不应该放在第一位！ 当其他人(或您，经过一段时间)查看提交历史记录时，他们将看到有缺陷的原始提交，挠头，直到后来，将其撒在提交日志中的某个地方，找到可以纠正原始提交内容的提交。错误。

Wouldn’t it be great if we could just correct our mistakes in the original commit? Here’s the good news: You can!

如果我们可以更正原始提交中的错误，那不是很好吗？ 这是个好消息：可以！

In this article, we’ll be looking at the Fixup tool that is part of Git’s Interactive Rebase command and see how it allows us to fix mistakes in old commits.

在本文中，我们将研究Git的Interactive Rebase命令中的Fixup工具，并查看它如何使我们能够修复旧提交中的错误。

关于交互式基础的一些话 (A Few Words About Interactive Rebase)

Before we go into the details and tackle an example case, I think it’s helpful to provide a very brief introduction to Interactive Rebase first.

在我们详细讨论示例案例之前，我认为先对Interactive Rebase进行非常简短的介绍会有所帮助。

You could say that Interactive Rebase is a set of tools that all have one purpose: They allow you to correct your commit history after the fact. You can do lots of fancy things with Interactive Rebase: delete old commits, change their messages, combine multiple commits, and much more. We won’t dive into these other use cases, but I’ll link to some good reading material at the end of this article.

您可以说Interactive Rebase是一组具有全部目的的工具：它们使您可以在事后更正提交历史。 您可以使用Interactive Rebase做很多花哨的事情：删除旧的提交，更改其消息，合并多个提交等等。 我们不会深入探讨这些其他用例，但是在本文结尾，我将链接到一些不错的阅读材料。

One last word of warning: Manipulating your commit history, as we will do shortly, is best performed on commits that have not been shared on a remote repository yet. The reason for this is simple: If you’ve already shared commits with your teammates, chances are they have already based their new work on those exact commits. If you manipulate them after the fact, you can expect tears and swear words.

警告的最后一个字：操作你的提交历史，我们会尽快做，最好是在尚未对远程资源库共享尚未提交执行。 原因很简单：如果您已经与队友共享了提交内容，那么他​​们很可能已经根据这些确切的提交内容进行了新工作。 如果您事后操纵它们，您可能会流泪和发誓。

So, to live a long and happy life, I suggest you use these tools only on your local commit history — before you integrate it into a shared team branch.

因此，为了长寿幸福地生活，建议您仅在本地提交历史记录上使用这些工具，然后再将其集成到共享的团队分支中。

有很多方法可以解决 (There Are Many Ways to Mess Up)

As you undoubtedly know, there are a million ways to mess up your code. You could have forgotten to add a file or should have deleted one. Maybe you should have removed some lines or you simply produced a typo! The beauty of the Fixup tool is that it doesn’t matter what exactly happened. We’ve made a mistake — and now we’re fixing it.

您无疑知道，有一百种方法来弄乱您的代码。 您可能忘记了添加文件，或者应该删除了一个文件。 也许您应该删除一些行，或者只是产生了错字！ Fixup工具的优点在于，到底发生了什么无关紧要。 我们犯了一个错误-现在我们正在解决它。

Our natural tendency, as we’ve already talked about, is to simply produce a new commit that fixes our mishap. The problem with this approach is that each time we do this, our commit history gets dirtier and dirtier — to the point where it becomes hard to follow and understand.

正如我们已经谈到的，我们的自然趋势是简单地产生一个新的提交来解决我们的不幸。 这种方法的问题在于，每次我们这样做时，我们的提交历史就会变得越来越肮脏，以至于很难理解和理解。

But here’s the good news: Using Fixup, we can keep working like this (simply producing a new commit that contains the corrections) but have a clean commit history at the end!

但这是个好消息：使用Fixup，我们可以像这样继续工作(简单地生成包含更正的新提交)，但最后会有干净的提交历史！

Here’s how Fixup does this:

Fixup的操作方法如下：

Photo by the author.

图片由作者提供。

The magic happens in that third step: Fixup applies the changes from our ugly band-aid commit to the original one and then discards the band-aid commit. We’re left with a clean commit history and no trace of a mistake at any point!

神奇的事情发生在第三步：Fixup将我们的丑陋创可贴更改应用于原始更改，然后丢弃创可贴提交。 我们留下了干净的提交历史记录，任何时候都没有任何错误的痕迹！

Let’s see how all of this works in practice!

让我们看看所有这些在实践中是如何工作的！

步骤1：制作创可贴 (Step 1: Producing the Band-Aid Commit)

The first step is to do whatever is necessary to fix the mistake. You’ll want to jump into your editor and make the fixes. For our example, let’s say our corrections are contained in the-fix.txt. We simply add this to the staging area and commit it — almost like a normal commit:

第一步是尽一切可能纠正错误。 您需要跳入编辑器并进行修复。 对于我们的示例，假设我们的更正包含在the-fix.txt 。 我们只需将其添加到登台区域并进行提交-几乎就像普通的提交一样：

$ git add the-fix.txt
$ git commit — fixup 2b504bee

The only specialty here is the --fixup option to the commit command. It’s here that we mention the broken original commit that we intend to fix. You can read that command as follows: “This new commit will fix the old commit with the hash 2b504bee.”

唯一的特色是commit命令的--fixup选项。 我们在这里提到了要修复的原始提交。 您可以按以下方式读取该命令：“此新提交将使用哈希2b504bee修复旧提交。”

Let’s take a look at our commit history using Tower, a Git desktop GUI:

让我们使用Git桌面GUI Tower来查看提交历史：

You’ll see that the newest item is the band-aid commit we just produced. Nothing spectacular, except for its commit message maybe. It’s the message of the old commit we want to fix prepended by fixup !.

您会看到最新的项目是我们刚刚制作的创可贴。 没有什么特别的，除了它的提交信息。 这是我们要修复的旧提交的消息，该消息由fixup !前缀fixup ! 。

We’re all set and can now start the Interactive Rebase session to perform the actual Fixup operation.

我们已经准备就绪，现在可以启动Interactive Rebase会话来执行实际的Fixup操作。

第2步：使用Interactive Rebase进行修复 (Step 2: Fixup With Interactive Rebase)

To start the Interactive Rebase session, we first have to take a look at our commit history once more:

要开始Interactive Rebase会话，我们首先必须再次查看我们的提交历史记录：

The commit that we want to correct is selected in the above screenshot. To be able to manipulate this part of the Git history, we need to start the Interactive Rebase session at least at the faulty commit’s parent revision! You can either provide that commit’s hash or simply provide how many commits behind the current HEAD commit it is:

在上面的屏幕截图中选择了我们要更正的提交。 为了能够操纵Git历史记录的这一部分，我们至少需要在错误的提交的父修订版上启动Interactive Rebase会话！ 您可以提供该提交的哈希值，也可以简单地提供当前HEAD提交后面有多少个提交：

# Option (a): provide a specific commit hash:
$ git rebase -i — autosquash 0023cddd# Option (b): provide how far behind the HEAD commit it is:
$ git rebase -i — autosquash HEAD~4

No matter which way you choose, the --autosquash option is the other important ingredient in this workflow. Remember the fixup ! prefix that our band-aid commit was given? When the autosquash option finds commits with such a prefix, it automatically knows that a fixup is intended.

无论选择哪种方式，-- --autosquash选项都是此工作流程中的另一个重要组成部分。 记住fixup ! 给出我们的创可贴提交的前缀？ 当autosquash选项找到带有此类前缀的提交时，它将自动知道要进行修复。

After executing one of the above commands, the Interactive Rebase session will start and you’ll see an editor window similar to this one:

执行上述命令之一后，Interactive Rebase会话将开始，您将看到一个与此类似的编辑器窗口：

The lines at the top of the file are the commits you just selected (either by providing a commit hash or a range behind HEAD). The good news is that Git already did all the heavy lifting for us: It marked up our band-aid commit with the fixup action keyword and moved it to the correct line. The latter needs a short explanation: The fixup action keyword works by combining the marked-up commit (here: line 2) with the commit above (here: line 1). Since Git already knew both the band-aid and the original, faulty commit, it already prepared everything for us.

文件顶部的行是您刚刚选择的提交(通过提供提交哈希或HEAD后面的范围)。 好消息是，Git已经为我们完成了所有繁重的工作：它使用fixup action关键字标记了我们的创可贴提交，并将其移至正确的行。 后者需要简短说明： fixup action关键字通过将标记的提交(此处：第2行)与上方的提交(此处：第1行)结合使用。 由于Git已经知道创可贴和最初的错误提交，因此它已经为我们准备了一切。

There’s nothing left for us to do but save this editor window and then close it. The Interactive Rebase session is then finished and leaves us with the following scenario:

除了保存此编辑器窗口然后将其关闭之外，我们别无选择。 然后，Interactive Rebase会话结束，并为我们提供了以下方案：

Two things are noteworthy:

有两点值得注意：

1. The old, faulty commit now shows the-fix.txt in its changeset — just like we would have wanted it in the first place!

   现在，错误的旧提交现在在其变更the-fix.txt显示the-fix.txt －就像我们最初想要的那样！

2. The band-aid commit is gone. Git discarded it after applying the contained changes to the original commit.
   创可贴的提交不见了。 在将包含的更改应用于原始提交之后，Git放弃了它。

To sum it up, our original commit is now correct (like it never had been faulty) and our commit history is clean without any of those ugly band-aid commits lingering around.

综上所述，我们最初的提交现在是正确的(就像从来没有过错一样)，并且我们的提交历史是干净的，没有任何丑陋的创可贴持久存在。

Feel free to open the good champagne because this is certainly a reason to celebrate!

随时打开好香槟，因为这无疑是值得庆祝的原因！

发掘互动基础的力量 (Discover the Power of Interactive Rebase)

We’ve barely scratched the surface of what Interactive Rebase can do for you! It’s a very powerful tool that can help you produce a cleaner, clearer commit history in your Git repositories.

我们几乎没有涉及Interactive Rebase可以为您做的事情的表面！ 这是一个非常强大的工具，可以帮助您在Git存储库中生成更清晰，更清晰的提交历史记录。

If you want to go deeper, here are some (free) resources that might be helpful:

如果您想更深入一点，这里有一些(免费)资源可能会有所帮助：

• The “First Aid Kit for Git” — a series of short videos with different use cases around “Undoing Mistakes with Git,” including Interactive Rebase.

  “用于Git的急救包”-一系列简短的视频，围绕“撤消Git的错误”使用不同的用例，包括Interactive Rebase。

• A video on CSS-Tricks on “Git Tricks for Getting Yourself Out of Trouble.”

  有关CSS技巧的视频，主题为“让自己摆脱困境的Git技巧” 。

Have fun becoming more productive with Git!

祝您使用Git变得更有效率！

翻译自: https://medium.com/better-programming/how-to-fix-your-mistakes-in-git-and-leave-no-trace-8919d112064b

git 修复中间版本