假设我有一个存储库，其文件夹结构如下：
Base
|-dir1
|-dir2
| |-subdir1
| |-subdir2
| |-subdir3
|-dir3
我在"dir-2"目录上执行"git-filter-repo"。现在我的文件夹结构是：
Base
|-dir2
| |-subdir1
| |-subdir2
| |-subdir3
在对"dir2"中的文件进行了一些更改后，我想将其合并回过滤掉的原始repo，并将结构重新恢复为这样：
Base
|-dir1
|-dir2 (updated with changes)
| |-subdir1
| |-subdir2
| |-subdir3
|-dir3
如何在保存历史的同时做到这一点？
如何在保存历史的同时做到这一点？
这个问题有一个普遍的答案——那就是，在保存历史的同时，我该如何做_____——在Git中，对于任何填充此空白的，即：Git中的History是提交。提交就是历史。这就是所有的历史。如果你有所有的提交，你就有所有的历史了。
因此，关于合并的特定问题的答案很简单：进行合并，并确保结果是您喜欢的。新提交只是将添加到现有提交中，即只添加更多历史记录。古老的历史仍然存在。
这里的微妙之处在于，你如何看待历史取决于你的立场。如果您在合并前的点运行git log，您将看到的历史就是您以前看到的历史。但是，如果您在合并时或经过合并的任何点运行git log，您将看到的历史记录可能会有所不同。尽管这种类比充其量是可疑的，但你可以把它想象成近距离观察一片长满庄稼的田地，然后试图观察同一片田地，你和这片长满作物的田地之间有一个大城市。字段没有改变，您现在无法查看，因为所有的高楼挡住了您的视线。
在Git中查看历史记录时，如果使用git log --follow或git diff --find-renames，Git将尝试检测重命名的文件。也就是说，我们有两个提交，每个提交都代表Git在您(或任何人(提交时所知道的所有文件的快照。我们将一个旧的快照L放在左边，将一个新的快照R放置在右边，并询问Git：L和R之间发生了什么变化
也许，在L中，有一个名为O的文件，该文件已不存在于R。但在R中，有一个名为N的文件，它在L不存在。如果重命名检测器打开，Git将尝试推断O和N是否代表同一文件。(这进入了以特修斯的祖父之斧或船问题为代表的身份形而上学。(如果Git决定O和N是同一个文件，Git将声称O被重命名为N，并向您展示这两个文件内容之间的差异(如果有的话(。否则，Git将声称O已删除，N已创建。
这也是你在Git中所能得到的。重要的是要知道Git何时决定重命名文件，而不是删除一个文件并创建另一个文件，但也要意识到这些代表相同的东西。此外，您可以打开或关闭Git的重命名检测器，并在一定程度上对其进行微调。这里有一些关于合并提交的陷阱，目前还没有简单的方法来解决它们。
也就是说，就保存历史而言，请记住：提交就是历史。如果你有所有的提交，你就有了所有的历史。