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

然后開始工作。