使用Visual Studio进行Git - 重复文件夹/文件名只有不同的大小写？

Question

提交和大写和重复文件 - 哦，我的！

我的儿子在SuperAdventure C# Tutorial工作，我让他承诺到当地的Git回购，并推到Github repo。在某个地方，他最终在他的仓库中出现了一些奇怪的错误，这些错误会在每次提交时交替更改特定文件，有时会对以下两个文件名显示相同的更改：

 SuperAdventure/SuperAdvetnure.cs
 superadventure/superadvetnure.cs

（是的 - 他在* .cs文件上拼错了）。踢球者是只有一个文件（大写的原始版本）。 Git似乎有时会认为更改是在这些文件中的一个或另一个，甚至是这两个文件中，并且在提交Git认为存在的更改之后，它只会看到刚刚提交的更改的反转（即，现已被删除，反之亦然）。

如果我查看Git Extensions中每个提交的历史记录，查看文件树选项卡，我可以看到从提交698f378a（第16.1课 - 重构）开始，文件树显示添加了未大写的{{1除了大写的原始文件之外，此文件夹和文件存在于每个将来的提交中。 superadventure/superadvetnure.cs文件夹中没有任何其他文件 - superadventure文件夹中的其他文件都没有重复，只有一个文件。

那么，这里的交易是什么？

由于Windows并不关心大小写 - 但是Unix确实如此，Git和Windows或Git和Visual Studio之间是否存在一些奇怪的交互？我不知道他是如何设法在Git仓库中获得不同的资本化。问题似乎是当Git试图将这两个文件放入工作目录时，它们只是互相覆盖。

我尝试了一些挑选和重新定位并得到上面描述的奇怪错误 - 但那是在我发现添加ghost文件重复的原始提交之前 - 可能从此之前的提交开始，rebasing将起作用？

有没有办法直接删除重复的文件？我想这可能搞砸了一些后续提交？

问题

解决此问题并删除重复的SuperAdventure文件夹和文件的最佳方法是什么？

奖金问题：首先如何发生这种情况？

Answer 1

是的，您可以删除它。最好在github界面中这样做，不要没有git识别删除错误文件的风险。之后再次克隆是有意义的。

奖励回答：除非你提供VS，git，你正在使用的界面等版本并尝试重现它，否则很难说。

只是一些观点：

• Git的核心是案例感知，但在Windows端口中有一些技巧可以使它在不区分大小写的filsystem上运行。他们可以有问题并随着时间的推移而改善
• 众所周知，VS有时会失去＆＃34;打开文件的情况，并将它们显示为小写。我自己也看过了，我似乎已经在这里讨论了它。
• 2017年以前的VS过去常常使用官方端口而不是替代库（libgit2），也许那里有一些问题。

我建议安装VS 2017和最新的git版本（或者它是否与VS捆绑？）并观察它是否再次发生。

Answer 2

从max630's answer开始，我能够在本地成功修复此回购问题（并非如他所建议的那样直接在Github上）。我不想在Github中修复它，因为我担心在Github的提交中直接删除有问题的ghost文件会产生副作用。

当我完成整个过程时，我发现我的担心可能是合理的 - 在重新定位期间从某些提交中删除ghost文件后，最终至少有一个没有更改的后续提交。如果我在Github中删除了文件，我不确定会怎么做。

以下是适合我的流程：

1. 使用Git Extensions Git GUI查看每个提交的“文件树”。在历史记录中向后移动，直到找到最早没有问题的提交。

2. 在最后一次良好的提交中创建一个名为fixedmaster等名称的新分支。

3. 重新显示从主分支到新的fixedmaster分支的提交，确保ghost文件不是每个提交的一部分。

   • 我使用git cherry-pick <commit>签出fixedmaster签出（实际上我使用了Cherry Pick的Git Extensions GUI选项）。
   • 在挑选之后，但在提交之前，请执行git status并查看是否包含ghost文件。如果是其中一个更改，或者显示为已添加或已删除的文件，我可以使用git reset HEAD <filename>（在我的情况下，文件名为superadventure/superadvetnure.cs）清除索引，并且实际上导致它完全消失（有道理：幽灵并不存在......）
   • 进行提交 - 您可以使用git commit --amend来改变现有提交，或者制作一个全新的提交。
   • 注意：可能有一种方法可以对从那里提交到当前主分支提交的所有提交进行交互式rebase，但是我遇到了一些问题，使得这项工作正常并且在此过程中迷失了方向。问题的一部分是，一旦问题被删除，一些提交就不再发生变化（它们最终被“鬼”提交！）。
   • 编辑：将其修复到我的电脑上后，我帮他修好了（当然，为了让他了解更多Git！）。樱桃采摘后有几次它在索引中有一些文件，而有些文件没有分页 - 通常这意味着涉及鬼文件。我们通过从索引中取消暂存所有文件来修复它，这将消除重影，然后重新添加它们，这只捕获了真正的变化。

4. 对fixedmaster完成此过程后，您需要对其他任何分支执行相同操作。

5. 您可以将master切换为fixedmaster，但请先考虑以下几点：

   • 让所有用户以某种方式了解这个问题。如果他们正在开发新的修补程序，他们需要等待获取新的分支并开始处理它们。当你换到新的分支时，你可以让它们变得非常混乱。实际上，您可能希望分阶段从旧主服务器转换为新主服务器。
   • 为了保留旧的分支，我建议在每个分支的末尾添加一个标记，然后转移到新分支 - 标记将保留断开的分支，直到您确定新的分支正在工作（或永久，如果需要）。它不会在那里用标签进行垃圾收集。标签比永久创建分支更可取，特别是因为您不希望任何人向它们添加提交。

6. 您可以将master重置为新的fixedmaster

   • 结账大师
   • 创建oldmaster或类似的标记。
   • 重置 - 执行fixedmaster提交
   • 删除分支fixedmaster
   • 现在master应位于固定分支的位置，旧的主分支存在，并在末尾标记。如果你想在将来摆脱它，只需删除标签。

7. 如果需要，重复其他分支

8. 强制将主控（和任何其他固定分支）推送到远程仓库。当然，如果你有很多用户不知道会发生这种情况，这会导致havok，如上所述。

还有其他方法可以获得更精细的细节，但是你可以了解它。