如何重新合并 GitHub 中已删除的文件夹？

Question

假设我有 3 个分支：main、dev 和 release dev 分支是使用主分支创建的，并且在主分支之前。 dev 分支有一个新文件夹，里面有一些新文件。

在 GitHub 中，我错误地从 dev 分支直接合并到 release 分支，而 dev 必须先合并到 main 分支，只有 main 分支必须与 release 分支合并。此时，在 dev 分支中的新文件夹在 release 分支中创建。

我立即恢复了发布分支中的合并。由于还原，新文件夹在发布分支中被删除。

接下来我将 dev 分支与 main 分支合并（这是我首先应该做的），然后将 main 分支与 release 分支合并。

但是，dev 分支中的新文件夹现在仅存在于主分支中，并且该文件夹及其文件不会在 release 分支中重新创建，因为该文件夹由于还原而被删除第一次合并。

如果我尝试创建一个从 main 到 release 分支的新合并请求，GitHub 会显示 release 分支是最新的，包含来自 main 的所有提交，并且 release 领先于 main。

main 合并到 release 的解决方案是什么，以便从 dev 分支到 main 的新文件夹在 release 分支中重新创建？

编辑 1：

无论我从 dev 合并到 release 都是正确的代码，但我不应该直接从 dev 合并到 release 作为练习。

Answer 1

git 不太关心文件;它更不关心文件夹。这里实际发生的是你有一些 git 认为不需要合并的提交。这是因为，就 git 而言，您已经合并了它们。

这里的关键点是，reverts 不会记录他们正在恢复的提交；每次运行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 也是分支的一部分。因此，合并只会跳过该提交 - 它不知道您后来恢复了更改。

因此，您需要“还原还原” - 请参阅 How do I "un-revert" a reverted Git commit? 和 How can I fix a reverted git commit? 以及可能许多其他类似问题。

在这种情况下，如果您运行 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（reverted revert）。

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

在所有这些中，git 应用的是一个更改：创建一个文件是一个更改，它的镜像是删除文件；在文件中添加一行也将是一个更改，并且镜像将删除该行。没有办法简单地“提醒 git 一个文件存在”——如果你试图对“丢失”的文件进行更改并合并它，你会遇到冲突，因为没有地方可以进行更改。

底线是：要在发布分支上重新创建文件，您需要创建一个新的提交来创建这些文件。

该提交需要位于文件尚不存在的分支上，因此在您的情况下，我认为您需要：

• 将“release”合并到“main”中：由于意外提交以及您恢复它的提交，它目前领先于“main”。
• 完成后，文件将在“main”上删除。要让它们恢复原状，您需要revert the revert。
• 这实际上将创建原始更改的新副本，重新创建文件。
• 现在将“main”合并到“release”中会根据需要创建文件。