可执行位问题与 Cygwin、Linux 或其他无关。
理论上你需要知道的一切
Windows 和 Linux（以及所有 Unixen）都有可执行程序文件的概念，这些文件在文件系统上被标记为此类文件。当 git 在工作空间中检出一棵树时，它会将其 blob 写入文件，并根据存储在树对象中的“模式”设置它们的权限。
“模式”基于Unix 模式，但受到更多限制，大概是为了便于移植（只有三种模式：普通文件、可执行文件和符号链接）。Windows 实现使用它来相应地设置NTFS 文件权限不会有任何问题。
这应该是故事的结局。可执行文件是 git 存储库中标记的可执行文件，并在所有用户系统上自动设置。
Visual Studio 怪癖
但是，VS 团队显然决定自动将一些（全部？）新签出的文件设置为可执行文件，即使它们在存储库中没有被标记为可执行文件。理论上听起来不错，很多人忘记或不真正理解“权限”的概念。
我说“显然”是因为它似乎与继承的权限有关。可能是他们没有真正的意图这样做，而是忘记自己设置适当的权限。
在实践中，这意味着更多的人会忘记并保持遗忘，只要他们都专门使用 Visual Studio 来操作存储库。那些使用任何其他工具（包括官方 git 命令）的人将无法开箱即用地执行程序，并且会被错误地告知使用 Visual Studio 而不是在存储库中实际将文件标记为可执行文件.
相反，在使用 VS 将文件从存储库中检出时，似乎没有办法不自动将文件设置为可执行文件。
以这种方式设置时，有一些巫毒会阻止 git 检测实际权限。这可能与权限继承和特殊权限有关。将文件资源管理器的安全窗格用于文件的属性以及 git 的源代码，您可能能够确定这是功能还是错误。（IMO，这一点没有实际意义，因为我认为工作空间中的权限应该与存储库中的权限相匹配，他们在使用官方 git 命令时会这样做。）
手动操作权限
使用 Windows 的文件资源管理器，使用文件属性窗口及其安全窗格。使用 Cygwin 或任何其他 Unix-y 环境，使用chmod.
Visual Studio 用户的真正修复
chmod +x .nuget/NuGet.exe
（或者使用文件资源管理器以 git 检测到它的方式正确设置可执行权限 - 就像chmod那样。）
git 应该检测到更改并将其解释为模式更改。git diff产量：
diff --git a/.nuget/NuGet.exe b/.nuget/NuGet.exe
old mode 100644
new mode 100755
现在提交它并将其推送到上游，这样其他人就不必这样做了。
将来，请尝试改用官方git clone命令或更好地研究此命令，以便向能够以理智的方式修复此问题的人写一份适当的错误报告。可能是双方都有事情要做（git 可能需要更智能地了解 Windows 上的继承权限，而 Visual Studio 在结帐时可能需要更加小心设置）。