Git - 如何回到历史并在两次提交之间创建一次提交

Question

我有一个关于如何返回 git 并从以前的版本生成新版本的问题。

例如，假设我在主分支中有以下提交历史记录：

v1.0 - v1.1 - v1.2 - v2.0 - v3.0

现在让我们假设我有一个版本为 v1.2 的客户端并且需要修复一个错误，但是它还不能升级到 2.0 版本。

如果我使用 git checkout 命令返回到 1.2 版，创建一个分支并像我提交到旧版本一样进行修复？

我希望我的序列看起来像这样：

v1.0 - v1.1 - v1.2 - v1.3 - v2.0 - v3.0

记住我知道 v1.3 修复不会在 v2.0 和 v3.0

Answer 1

记住我知道 v1.3 修复不会在 v2.0 和 v3.0

不过，这不是你画的。 为了绘制它，让我们将其重新绘制为一系列提交——Git 实际存储的内容：

     tag:v1.0
        |
        v      tag:v1.1
...--●--●         |
         \        v         tag:v1.2
          ●--...--●            |
                   \           v      tag:v2.0
                    ●--●--...--●         |
                                \        v      tag:v3.0
                                 ●--...--●         |
                                          \        v
                                           ●--...--●
                                                    \
                                                     ●--...  <-- master

在这里， master是一个分支名称，标识分支master上的最新提交。 每个不同的tag:...都是一个标签名称，标识构成发布给某人的版本的特定提交。

您现在想要返回并创建一个指向tag:v1.2指向的同一个提交的新分支名称。 没关系：

     tag:v1.0
        |
        v      tag:v1.1
...--●--●         |
         \        v         tag:v1.2
          ●--...--●            |
                   \           v      tag:v2.0
                    ●--●--...--●  <------|------- release/1
                                \        v      tag:v3.0
                                 ●--...--●         |
                                          \        v
                                           ●--...--●
                                                    \
                                                     ●--...  <-- master

●这里的每个实线代表一次提交。 提交在 Git 中是真实的、实际的和非常具体的东西：每个提交都有自己唯一的哈希 ID。 标记名称和分支名称不太可靠，因为它们可以四处移动。 标签名称不应移动； 移动一个是对它们应该如何使用的一种违反。 但是，分支名称会自行移动。 您现在可以git checkout release/1以获取由名称tag:v1.2和release/1标识的提交，然后进行新的提交，我们将在此处表示为○ ：

     tag:v1.0
        |
        v      tag:v1.1
...--●--●         |
         \        v         tag:v1.2
          ●--...--●            |
                   \           v      tag:v2.0
                    ●--●--...--●--○  <---|------- release/1
                                \        v      tag:v3.0
                                 ●--...--●         |
                                          \        v
                                           ●--...--●
                                                    \
                                                     ●--...  <-- master

请注意没有其他任何变化。 确实有两件事发生了变化：

• 你有一个新的提交○ ，并且
• 你的名字release/1标识了这个新的提交，因为当你创建一个新的提交时，你签出的分支名称会自动移动。

这个新提交不是通向master的提交链的一部分。 它独立存在。 你可以制作一个新标签来记住它的哈希 ID 以备将来使用，因为哈希 ID 又大又丑，如果你愿意的话，人类难以记住。 如果愿意，您可以在标记此提交之前进行更多新提交。

最后，这就是版本控制的全部内容：它保留您所做的每一次提交，以便您可以返回它，查看它，测试它的错误，在需要时对其进行修复，并继续开发.

如果您的问题是“如何”，那么您已经自己回答了：创建一个指向所需提交的分支名称，然后进行新的提交。 例如：

git checkout -b release/1 v1.2

然后开始工作。