我已经获得了很多“媒体文件”，并且我正在寻找一种管理它们的方法，这样拉动原始文件的更新就可以“无缝”进行。我会尝试用一个例子来解释。
假设我从互联网上购买了一堆“猫图片和视频”捆绑包（以zip文件形式分发）。它们都有不同的目录结构和命名约定，但这对我的“猫库应用”来说是行不通的，因此我将这些文件提交给git（例如），然后将其移动并重命名为一个单一的“逻辑”目录结构，然后也提交这些更改。
现在，当我完成对“猫库应用”的编码时，这些捆绑软件中的很多文件都已更新，比如说具有更高的分辨率，或者需要额外的Photoshoping，...所以，我想将这些更改应用到我的文件，但名称和位置不再匹配。
那么，我该怎么做（使用git或其他方法）？
答案 0 :(得分：1)
编辑：部分重写；我在原始答案中说的是正确的，但我隐式地得出了一个不正确的结论（因为在考虑合并时，我错误地使用了相似性度量标准）。
我对如何最好地处理它的建议没有改变。
我会说你不是在git的“最佳位置”上工作。我没有针对其他工具的建议，无论如何，对于SO而言，工具的建议都是不合时宜的。我并不是说您不能使用git，但这是您要面对的问题：
1）您正在跟踪可能较大的二进制文件，这不是git的优势。
2）您想跟踪重命名。在git中，重命名不是直接跟踪的，而是使用相似性度量从删除和添加中重建的。因此，您将不断依赖git解决“我们“移动”文件并由他们编辑文件”这类“冲突”。这并不是git的最强优势，尤其是当有很多文件在移动时。
您可以使用git LFS之类的工具缓解第一个问题。
最初，我注意到您的许多更新的相似性指标均较低（可能为0％）。是的，但是只要始终在一个提交中进行更新，然后在一个单独的提交中进行移动，就可以解决该问题。
因此，您可以通过保留原始文件结构的“上游”分支来简单地处理它，始终先将更新应用于该分支而不移动文件，然后将该分支合并到您的文件中大师（您在其中进行了初始重命名）。只要没有文件重复，git就能计算出先前的合并将文件“移动”到新位置，并在生成后续合并时将其与更改保持一致。但是，要移动一大堆文件可能会很慢，并且可能需要您调整配置设置，以限制git尝试解析的重命名次数（请参见diff.renameLimit）。
但是为了避免重命名检测的潜在问题，您可能需要这样做：
1）将文件保存在存储库中的原始位置（可能使用LFS或类似文件）
2）为将它们移到统一目录结构中的过程编写脚本，并对脚本进行源代码控制（类似于更典型的软件项目的由源代码控制的自动构建脚本）