我们的开发人员混合使用Windows和基于unix的操作系统。因此，在Unix机器上创建的符号链接成为Windows开发人员的一个问题。在Windows (MSysGit)中，符号链接被转换为一个文本文件，并带有它所指向的文件的路径。相反，我想将符号链接转换为实际的Windows符号链接。
我对此的(更新的)解决方案是:
编写一个检出后脚本，递归地查找“符号链接”文本文件。 将它们替换为Windows符号链接(使用mklink)，具有与虚拟“symbolic link”相同的名称和扩展名 通过在文件.git/info/exclude中添加一个条目来忽略这些Windows符号链接
我还没有实现这个方法，但我相信这是解决这个问题的可靠方法。
如果有的话，你认为这种方法有什么缺点? 这个后签出脚本是可实现的吗?也就是说，我能递归地找到Git创建的虚拟“符号链接”文件吗?
当前回答
我们使用的一个简单的技巧是调用git add——连续两次。
例如，我们的Windows 7提交脚本调用:
git add --all
git add --all
第一个add将链接视为文本，并添加用于删除的文件夹。
第二个add正确地遍历链接，并通过恢复文件来撤销删除操作。
它没有其他一些提议的解决方案那么优雅，但它是对添加了符号链接的一些遗留环境的简单修复。
其他回答
我一直在寻找一种简单的解决方案来处理Windows上的Unix符号链接。非常感谢您在之前的回答中提供Git别名。
可以对rm-符号链接进行一个小小的优化，以便在别名意外第二次运行时它不会删除目标文件夹中的文件。请观察循环中的新if条件，以确保在逻辑运行之前文件不是到目录的链接。
git config --global alias.rm-symlinks '!__git_rm_symlinks(){
for symlink in $(git ls-files -s | egrep "^120000" | cut -f2); do
*if [ -d "$symlink" ]; then
continue
fi*
git rm-symlink "$symlink"
git update-index --assume-unchanged "$symlink"
done
}; __git_rm_symlinksenter
它应该在MSysGit中实现，但是有两个缺点:
符号链接只在Windows Vista及以后版本中可用(在2011年应该不是问题，但它确实是…)，因为旧版本只支持目录连接。 微软认为符号链接存在安全风险，因此默认情况下只有管理员可以创建符号链接。您需要提升Git进程的特权，或者使用fstool在您工作的每台机器上更改此行为。
我做了一个快速搜索，这方面的工作正在积极进行;见第224期。
我们使用的一个简单的技巧是调用git add——连续两次。
例如，我们的Windows 7提交脚本调用:
git add --all
git add --all
第一个add将链接视为文本，并添加用于删除的文件夹。
第二个add正确地遍历链接，并通过恢复文件来撤销删除操作。
它没有其他一些提议的解决方案那么优雅，但它是对添加了符号链接的一些遗留环境的简单修复。
您可以通过查找模式为120000的文件来查找符号链接，可能使用以下命令:
git ls-files -s | awk '/120000/{print $4}'
一旦你替换了链接，我建议使用git update-index——assume-unchanged将它们标记为不变，而不是将它们列在.git/info/exclude中。
对于那些在Windows Vista、Windows 7或更高版本上使用Cygwin的人来说，原生git命令可以创建“适当的”符号链接，这些符号链接可以被Windows应用程序(如Android Studio)识别。你只需要设置CYGWIN环境变量来包含winsymlinks:native或winsymlinks:nativestrict，就像这样:
export CYGWIN="$CYGWIN winsymlinks:native"
这样做的缺点(也是一个很重要的缺点)是Cygwin shell必须是“以管理员身份运行”，这样它才能拥有创建这些符号链接所需的操作系统权限。但是，一旦创建了它们，就不需要特殊的权限来使用它们。只要它们没有在存储库中被另一个开发人员更改，git就可以在正常的用户权限下正常运行。
就我个人而言，我只对Windows应用程序(即非cygwin)导航的符号链接使用这种方法，因为这增加了难度。
有关此选项的更多信息，请参阅堆栈溢出问题:如何在Windows 7中使用Cygwin创建符号链接
