假设我有一个具有如下文件夹结构的存储库：
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 github git-filter-branch git-filter-repo
如何在保留历史记录的同时做到这一点？
这个问题有一个普遍的答案——即，我如何在保存历史的同时做_____？——在 Git 中，对于任何可以填补这个空白的，以及也就是说：在 Git 中，历史就是提交。提交是历史。这就是所有的历史。如果你有所有的提交，你就有了所有的历史。
因此，关于合并的特定问题的答案很简单：进行合并并确保结果是你喜欢的。新的提交只是 add 到现有的提交中，即，只是添加更多的历史。古老的历史还在。
这里的微妙之处在于，你如何看到历史取决于你的立场。如果您从之前合并的那一点开始运行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 是否代表相同的文件。 （这进入了metaphysics of identity，由祖父的斧头或Ship of Theseus 问题表示。）如果Git 确定O 和N 是同一个文件，Git 将声称@987654333 @ 已重命名为 N，并向您展示这两个文件内容之间的差异（如果有）。否则，Git 将声称 O 已删除，N 已创建。
这就是你在 Git 中所能获得的一切。了解何时Git 将决定重命名文件，而不是删除一个文件并创建另一个文件，这一点很重要，但同样重要的是要意识到这些代表相同的东西。此外，您可以打开或关闭 Git 的重命名检测器，并且可以在一定程度上对其进行微调。这里有一些关于合并提交的陷阱，目前没有简单的方法来解决它们。
也就是说，就保留历史而言，请记住：提交是历史。如果你有所有的提交，你就有了所有的历史。
【讨论】：