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

Question

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

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

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

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

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

如果我尝试创建一个从主分支到发布分支的新合并请求，GitHub 显示发布分支是最新的，包含来自主分支的所有提交，并且发布在主分支之前。

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

编辑 1：

无论我从 dev 合并到 release 什么都是正确的代码，但只是我不应该直接从 dev 合并到 release 作为实践。

Answer 1

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 也是分支的一部分。因此合并将简单地跳过该提交 - 它不知道您后来恢复了更改。

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

在这种情况下，如果您运行 git revert def456，您创建了第三次提交，789aaa，它撤消了撤消 - 换句话说，它重新创建了提交 abc123 的原始更改。如果你认为还原是镜像，那么还原还原就是镜像的镜像——和原来的一样。

鉴于上图，我们可能首先将“release”合并到“my_branch”，这样abc213和def456就在那个分支上。这样，我们就可以在某个地方放置我们的“还原的还原”，而无需直接提交“发布”。然后当我们还原 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”上删除。要取回它们，您需要 还原还原。
这实际上会创建原始更改的新副本，重新创建文件。
将“main”合并到“release”现在将根据需要创建文件。

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

How to re-merge deleted folder in GitHub?

git

version-control

merge

github