在Windows在Windows上创建的Directory Symlinks由于某种原因将其推入File Symlinks之后，将其推向git并重新串起。这导致"目录名称无效"错误。
但是，这仅在符号链接中包含多个子目录的路径中时才发生。如果只有一个子目录，他们将继续工作正常。另外，它们在bash壳中仍然可以正常工作。
以下是原始回购中的列表：
05/01/2019 07:50 AM <SYMLINKD> ACN [....acnInstalled]
05/01/2019 08:00 AM <SYMLINKD> ACNProxy [....acnproxybin]
04/30/2019 01:29 PM <SYMLINKD> API [..swupdate-2bin]
05/01/2019 08:24 AM <SYMLINKD> AnalyticsPlugin [......analyticsinstallerplugin]
05/01/2019 08:08 AM <SYMLINKD> Encryption [..protocolstrunkEncryption]
05/01/2019 08:17 AM <SYMLINKD> HelpFiles [..helpwwb6]
05/01/2019 08:34 AM <SYMLINKD> PrePackagedDatabase [..wwb6database]
05/01/2019 09:34 AM <SYMLINKD> ToastNotifications [..toastnotifications]
05/01/2019 08:01 AM <SYMLINKD> acnComponent [......acn_component]
05/01/2019 07:45 AM <SYMLINKD> dante_lic_mac [..dante_mac_fixWWB_compressed_lic_info_files]
05/01/2019 08:05 AM <SYMLINKD> devCategory [......devicedescriptionfilesdevCategory]
05/01/2019 08:10 AM <SYMLINKD> shared [....frequencycompatFrequencyCompatibilityCalculator]
05/01/2019 09:26 AM <SYMLINKD> shared [....swupdatesrcshared]
05/01/2019 08:06 AM <SYMLINKD> skuConversion [......skuconversionsrc]
将符号链接推向远程git服务器并重新登录回购后，那些指向一个多个子目录列出的路径的符号链接已更改为文件symlinks：
05/01/2019 09:28 PM <SYMLINK> ACN [....acnInstalled]
05/01/2019 09:28 PM <SYMLINK> ACNProxy [....acnproxybin]
05/01/2019 09:28 PM <SYMLINK> API [..swupdate-2bin]
05/01/2019 09:28 PM <SYMLINKD> AnalyticsPlugin [......analyticsinstallerplugin]
05/01/2019 09:28 PM <SYMLINK> Encryption [..protocolstrunkEncryption]
05/01/2019 09:28 PM <SYMLINKD> HelpFiles [..helpwwb6]
05/01/2019 09:29 PM <SYMLINKD> PrePackagedDatabase [..wwb6database]
05/01/2019 09:28 PM <SYMLINKD> ToastNotifications [..toastnotifications]
05/01/2019 09:28 PM <SYMLINKD> acnComponent [......acn_component]
05/01/2019 09:28 PM <SYMLINK> dante_lic_mac [..dante_mac_fixWWB_compressed_lic_info_files]
05/01/2019 09:28 PM <SYMLINK> devCategory [......devicedescriptionfilesdevCategory]
05/01/2019 09:28 PM <SYMLINK> shared [....frequencycompatFrequencyCompatibilityCalculator]
05/01/2019 09:28 PM <SYMLINK> shared [....swupdatesrcshared]
05/01/2019 09:28 PM <SYMLINK> skuConversion [......skuconversionsrc]
任何人都可以解释这种行为吗？
在bash shell中，所有符号链接在原始和克隆的存储库中均看起来相同(和功能(：
lrwxrwxrwx 1 ******* 1049089 17 May 1 21:28 ./wwb6/API -> ../swupdate-2/bin
lrwxrwxrwx 1 ******* 1049089 46 May 1 21:28 ./wwb6/dante_lic_mac -> ../dante_mac_fix/WWB_compressed_lic_info_files
lrwxrwxrwx 1 ******* 1049089 19 May 1 21:28 ./wwb6/datastorage/ACN -> ../../acn/Installed
lrwxrwxrwx 1 ******* 1049089 18 May 1 21:28 ./wwb6/datastorage/ACNProxy -> ../../acnproxy/bin
lrwxrwxrwx 1 ******* 1049089 22 May 1 21:28 ./wwb6/datastorage/libdatastorage/acnComponent -> ../../../acn_component
lrwxrwxrwx 1 ******* 1049089 43 May 1 21:28 ./wwb6/datastorage/libdatastorage/devCategory -> ../../../devicedescriptionfiles/devCategory
lrwxrwxrwx 1 ******* 1049089 26 May 1 21:28 ./wwb6/datastorage/libdatastorage/skuConversion -> ../../../skuconversion/src
lrwxrwxrwx 1 ******* 1049089 29 May 1 21:28 ./wwb6/Encryption -> ../protocols/trunk/Encryption
lrwxrwxrwx 1 ******* 1049089 54 May 1 21:28 ./wwb6/FrequencyCompatibility/shared -> ../../frequencycompat/FrequencyCompatibilityCalculator
lrwxrwxrwx 1 ******* 1049089 11 May 1 21:28 ./wwb6/HelpFiles -> ../helpwwb6
lrwxrwxrwx 1 ******* 1049089 33 May 1 21:28 ./wwb6/Installation/Mac/AnalyticsPlugin -> ../../../analyticsinstallerplugin
lrwxrwxrwx 1 ******* 1049089 15 May 1 21:29 ./wwb6/PrePackagedDatabase -> ../wwb6database
lrwxrwxrwx 1 ******* 1049089 25 May 1 21:28 ./wwb6/SWUpdate/shared -> ../../swupdate/src/shared
lrwxrwxrwx 1 ******* 1049089 21 May 1 21:28 ./wwb6/ToastNotifications -> ../toastnotifications
请注意，所有这些都是在Windows 10机器上完成的。但是，远程存储库位于Linux服务器上。我故意在Windows机器上没有管理员的权利，因为开发人员也没有这些权利，并且符号链接应该为他们工作。
要在Windows中使用Symlinks，我进行了以下操作：
- 安装git bash时启用符号链接支持;
将以下条目添加到用户的.bash_profile：
export MSYS=winsymlinks:nativestrictexport CYGWIN=winsymlinks:nativestrict启用git中的符号链接支持：
git config --global core.symlinks true通过使用组策略编辑器将用户添加到创建符号链接策略；
确保允许用户评估本地符号链接：
fsutil behavior query symlinkevaluation...并非如此：
在管理员中运行以下命令。fsutil behavior set symlinkevaluation L2L:1良好的度量，包括-c core.symlinks = true切换到git克隆命令。
进行所有这些更改后，创建和遍历目录符号链接在Windows中效果很好，而无需用户必须在本地管理员组中。直到他们被推到Linux并重新下载。
更新：在克隆指点转换为子模块内的目录之后，将类型从symlinkd更改为符号链接的符号链接。当容器项目被克隆时，创建了子模块的根目录，但是直到容器项目的克隆(Symlinks Live(完成后，内容尚未拉下：
git clone --recursive -c core.symlinks=true ssh://<server>:7999/<repo>
当目标尚不存在时，Windows似乎不会重新创建目录符号链接。它代替了类型文件符号链接创建它们。不过，这确实从Windows命令行(如Linux中所做的(工作：
mklink /d symlink ..<some non-existing directory><another non-existing directory>
...工作正常。
我目前的解决方法是简单地删除并恢复它们：
$ find . -type l -delete
$ git checkout .
Updated 14 paths from the index
不过要解决这个问题。
这似乎是一个待处理问题，在git-for-windows/git问题1027
中报告创建了无法使用的符号链接。
即使以后创建目标目录，Symlink也无法从Windows Explorer中使用。
一个更准确的问题，git-for-fordows/git问题1646应该在2.17 中固定。
尽管如此，OP Jozef还是创建了一个新问题：git-for-windows/git问题2177。
维护者Johannes Schindelin(github.com/dscho(刚刚添加：
不幸的是，git的内部数据模型具有非常单独的符号链接的视图。
在Windows的Git中，我们通过尝试确定目标的类型(如果存在(来解决。在您的情况下，启发式休息。但是，我们最近介绍了该功能，您可以在
.gitattributes中声明Symlink类型：只需在该文件中添加一行(或使用该行以内容创建该文件，如果不存在(：my_symlink_name symlink=dir当然，您需要添加和提交此文件。
我在此信息之后对
.gitattributes线进行建模：mklink /d symlink ..<some non-existing directory><another non-existing directory>
.gitattributes中的第一列始终是文件名或文件名模式
OP确认：
在运行git 2.21的Windows 10框上效果很好(必须创建5个
.gitattributes文件(
它在运行git 2.17的Windows 7框上不起作用。
约翰内斯指出了Windows v2.19.1(2018年10月5日(的Git
现在可以通过
.gitattributes指定要创建的符号类型(目录或文件(。
请参阅提交25A7F44。
symlinks：
在Windows上，符号链接具有类型："文件符号"必须指向 文件和"目录Symlink"必须指向目录。如果是 Symlink的类型不匹配其目标，它不起作用。
git不会在索引或树中记录符号的类型。
在结帐时，它会猜测该类型，仅当目标存在时才有效 在创建符号链接时。情况通常不是这样， 例如，当链接指向子模块内的目录时。
symlink属性允许您明确设置Symlink的类型 对于file或dir，因此Git不必猜测。如果您在其他文件上有一组符号链接，则可以：
------------------------ *.gif symlink=file ------------------------告诉git，符号链接指向目录，请使用：
------------------------ tools_folder symlink=dir ------------------------在Windows以外的其他平台上忽略了
symlink属性 由于它们没有区分不同类型的符号链接。