如何在GitHub中重新合并已洗掉的檔案夾？

考慮到我有 3 個分支：main、dev 和 release dev 分支是使用 main 分支創建的，并且在 main 分支之前。dev 分支有一個新檔案夾，其中包含一些新檔案。

在GitHub中，我錯誤地從dev分支直接合并到release分支，而dev必須先合并到main分支，只有main分支必須和release分支合并。此時，dev 分支中的新檔案夾在 release 分支中創建。

我立即在發布分支中恢復了合并。由于恢復，新檔案夾在發布分支中被洗掉。

接下來我將 dev 分支與 main 分支合并（這是我首先應該做的），然后將 main 分支與 release 分支合并。

但是，dev 分支中的新檔案夾現在僅存在于主分支中，并且該檔案夾及其檔案不會在發布分支中重新創建，因為該檔案夾因第一次合并的恢復而被洗掉。

如果我嘗試從 main 到 release 分支創建一個新的合并請求，GitHub 會顯示 release 分支與 main 的所有提交都是最新的，并且 release 是在 main 之前。

將 main 合并到 release 的解決方案是什么，以便在 release 分支中重新創建從 dev 分支到 main 的新檔案夾？

編輯 1：

無論我從 dev 合并到 release 都是正確的代碼，但只是作為一種實踐，我不應該直接從 dev 合并到 release。

uj5u.com熱心網友回復：

git 不太關心檔案；它更不關心檔案夾。這里實際發生的是你有一些git 認為不需要合并的提交。那是因為，就 git 而言，您已經將它們合并了。

這里的關鍵點是還原不記錄他們正在還原的提交；每次運行時git revert，它只會創建一個新提交，就像原始提交的鏡像一樣。假設您創建提交 abc123，然后運行git revert abc123：這將創建一個新提交 def456，它撤消abc123 的更改；但它不會撤消該分支歷史記錄中提交 abc123 的存在。

假設您的原始更改是提交 b1b1b1，而 abc123 是您將其合并以發布；您的歷史記錄現在可能如下所示：

                                       release
                                          |
                                          v
                ---------<* abc123 <- def456
              /          /
... <- 000aaa           /
             \         /
              <- b1b1b1
                   ^        
                   |        
               my_branch

現在，每當您嘗試將“my_branch”合并到“release”時，git 都會查找該分支上尚不存在的提交。提交 abc123 仍然是分支的一部分，并且由于將 b1b1b1 記錄為其父級，因此 b1b1b1 也是分支的一部分。所以合并只會跳過那個提交——它不知道你后來恢復了更改。

因此，您需要“還原還原” - 請參閱如何“取消還原”還原的 Git 提交？以及如何修復恢復的 git 提交？可能還有很多其他類似的問題。

在這種情況下，如果您運行git revert def456，則會創建第三次提交 789aaa，這會撤消撤消操作 - 換句話說，它會重新創建來自提交 abc123 的原始更改。如果您將還原視為鏡像，那么還原還原就是鏡像的鏡像 - 與原始影像相同。

鑒于上圖，我們可能首先將“release”合并到“my_branch”，以便 abc213 和 def456 位于該分支上。這樣，我們就可以在某個地方放置我們的“revert of the revert”，而無需直接提交“release”。然后當我們還原 def456 時，結果是這樣的：

                                       release
                                          |
                                          v
                ---------<* abc123 <- def456
              /          /                 \
... <- 000aaa           /                   \
             \         /                     \
              <- b1b1b1 ---------------------<* c2c2c2 <- 789aaa
                                                            ^        
                                                            |        
                                                        my_branch

現在，如果我們要求 git 將“my_branch”合并到“release”中，它會再次查找目標分支上尚不存在的提交。在這種情況下，它會找到提交 c2c2c2（沒有更改的合并提交）和 789aaa（還原的還原）。

                                                                  release
                                                                    |
                                                                    v
                ---------<* abc123 <- def456 -------------------*> 999fff
              /          /                 \                   /
... <- 000aaa           /                   \                 /
             \         /                     \               /
              <- b1b1b1 ---------------------<* c2c2c2 <- 789aaa
                                                            ^        
                                                            |        
                                                        my_branch

在所有這些中，git 應用的是更改：創建檔案是更改，其鏡像是洗掉檔案；在檔案中添加一行也是一種更改，鏡像將洗掉該行。沒有辦法簡單地“提醒 git 檔案存在”——如果您嘗試對“丟失”的檔案進行更改并合并它，則會發生沖突，因為無處可進行更改。

底線是：要在發布分支上重新創建檔案，您需要創建一個新提交來創建這些檔案。

該提交需要位于檔案尚不存在的分支上，因此在您的情況下，我認為您需要：

• 將“release”合并到“main”中：由于意外提交，它當前在“main”之前，以及您恢復它的提交。
• 完成后，檔案將在“main”上洗掉。為了讓他們回來，你需要恢復 revert。
• 這實際上將創建原始更改的新副本，重新創建檔案。
• 將“main”合并到“release”現在將根據需要創建檔案。

標籤：混帐 github 合并 版本控制

上一篇：gitcheck-ignore輸出未忽略的檔案

下一篇：Git簽名驗證