☰

TFS：git web 源代码浏览器中的不一致

tag-icon • tag-icon git team-foundation-server path
TFS：git web 源代码浏览器中的不一致

我们一直在使用本地 Team Foundation Server v 15.117.27414.0.。

一切都运行良好，除了在项目的 Web 门户上，在代码页面（代码资源管理器）上，git repo 中的所有文件都没有出现。例如，我们有一个带有 Models 文件夹的 MVC 项目，其中有 11 个类，但只有 7 个出现在网页上。项目的显示方式还存在其他问题。例如，有两个项目文件夹具有相同的名称（一个字符大小写不匹配），内容相似，而实际上应该有一个。

侧边栏显示两个同名的文件夹 - 但不是所有文件！

所有这些都让人困惑。除此之外，一切都正常。我们可以克隆项目或将其下载为 zip 文件，所有文件都在那里。只是它在 TFS 门户的“代码”选项卡下的显示方式让人困惑。

答案1

Git 是区分大小写的版本控制系统。因此，它允许您提交仅大小写不同的文件和文件夹。这是完全合法的，并且 Azure DevOps 和 Team Foundation Server（以及实际上每个 Git 托管提供商）必须允许和支持这一点。

您可以通过git ls-tree HEAD在存储库中运行来查看这一点。它将显示两种大小写变体的文件。

发生了以下两种情况之一：

  • 有人在区分大小写的文件系统（如 Linux）上克隆了您的存储库，并创建了一个仅大小写不同的目录，向其中添加了文件并提交了这些文件。这是合理的不太可能。
  • 很多更多的可能是有人将他们的存储库克隆到了案例上不敏感文件系统（如 Windows）并禁用core.ignorecase. core.ignorecase指示 Git 你处于不区分大小写的文件系统上，并且如果你在存储库中已经git add FOO/file.txt存在名为的目录时运行foo，则你实际上想要使用现存的目录。

core.ignorecase不是应该改变的设置。这不是一个选项。这是一个缓存值。Git 在创建存储库时会发现您的文件系统功能（区分大小写、Unicode 功能）并缓存它们，这样它就不必在每个命令上重新发现这些信息。

此值不应被改变，否则您将面临类似的问题。

要解决此问题，您可以将一种情况重命名为另一种情况。例如，如果您有一个存储库，其中包含一个名为 的文件夹foo和另一个名为 的文件夹FOO。假设您有两个文件，foo/bar和FOO/baz：

% git ls-files --stage
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0   FOO/baz
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0   foo/bar

要解决此问题，请确定要保留哪个名称（foo或FOO）并重命名另一个。您需要使用git mv以下-f标志：

% git mv -f FOO/baz foo/baz
% git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    FOO/baz -> foo/baz

您可以检查该问题以解决问题。

如果你有两个文件名称相同但大小写不同，您需要决定保留哪个名称。

% git ls-files --stage
100644 ba578e48b183662ddf9b38682cc52fb80066ce6d 0   FOO/bar
100644 5716ca5987cbf97d6bb54920bea6adde242d87e6 0   foo/bar

要删除其他文件，请使用标志--cached来git rm防止将其从磁盘中删除。

% git rm --cached FOO/bar
% git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    deleted:    FOO/bar

相关内容