下面是一个PowerShell脚本，用Windows替换Unix符号链接。

# This fixes permission denied errors you might get when
# there are Git symbolic links being used on repositories that
# you share in both POSIX (usually the host) and Windows (VM).
#
# This is not an issue if you are checking out the same
# repository separately in each platform. This is only an issue
# when it's the same working set (AKA make a change without
# committing on OS X, go to Windows VM and Git status would show
# you that change).
#
# Based on this answer on Stack Overflow: http://stackoverflow.com/a/5930443/18475
#
# No warranties. Good luck.
#
# NOTE: It must be run in elevated PowerShell

$ROOT = $PWD

$symlinks = &git ls-files -s | gawk '/120000/{print $4}'
foreach ($symlink in $symlinks) {
  $content = &Get-Content $symlink
  $content = $content.Replace("/", "\")
  $filename = $symlink.Split("/")[-1]
  cd (dirname $symlink)
  rm $filename
  echo Linking $content -> $filename
  New-Item -ItemType SymbolicLink -Path $filename -Target $content
  &git update-index --assume-unchanged $symlink
  cd $ROOT
}

我刚刚尝试了Git 2.30.0(发布2020-12-28)。

这并不是一个完整的答案，但还是有一些有用的花边新闻。(你可以随意做出自己的回答。)

Git Wiki入口

在安装Git for Windows时，有一个文档链接

这个链接把你带到这里:https://github.com/git-for-windows/git/wiki/Symbolic-Links——这是一个相当长的讨论。

供你参考:至少有三种“链接”。只是为了强调这个维基条目的一个重要方面:我不知道这一点，但有几种方法在表面上都是“某种”符号链接，但在技术层面上是非常不同的:

git bash's "ln -s" Which just copies things. Oh, boy. That was unexpected to me. (FYI: Plain Cygwin does not do this. Mobaxterm does not do this. Instead they both create something that their stat command actually recognizes as "symbolic link".) cmd.exe's builtin "mklink" command with the "/D" parameter Which creates a directory symbolic link. (See the Microsoft documentation) cmd.exe's builtin "mklink" command with the "/J" parameter. Which creates a directory junction AKA soft link AKA reparse point. (See the Microsoft documentation.)

发行说明条目

此外，在发布说明中还会不断弹出符号链接。截至2.30.0，这里仍然被列为“已知问题”:

在1703年以前的Windows 10上，或者当开发人员模式被关闭时，克隆带有符号链接的存储库时需要特殊权限，因此默认情况下禁用对符号链接的支持。使用git clone -c core。symlinks=true <URL>来启用它，参见这里的详细信息。

因此，自从发布了很多这些答案以来，Git已经发生了变化，下面是正确的指令，以使符号链接在Windows中正确工作:

2018年8月

1. 确保Git安装时带有符号链接支持

2. 告诉Bash创建硬链接而不是符号链接

(git)文件夹/ etc / bash . bashrc

添加到底部- MSYS=winsymlinks:nativestrict

3.将Git配置设置为使用符号链接

git config core.symlinks true

or

git clone -c core.symlinks=true <URL>

注意:我已经尝试将其添加到全局Git配置中，但目前它对我来说并不适用，所以我建议将其添加到每个存储库中…

4. 提取存储库

注意:除非您在最新版本的Windows 10中启用了开发人员模式，否则您需要以管理员身份运行Bash来创建符号链接

5. 重置所有符号链接(可选)

如果您有一个现有的存储库，或者正在使用子模块，您可能会发现符号链接没有被正确地创建，因此可以运行这些命令来刷新存储库中的所有符号链接。

find -type l -delete
git reset --hard

注意:这将重置自上次提交以来的所有更改，所以请确保您已经先提交了

请注意更新

对于大多数受困于符号链接和git以及与*nix系统共享repo的Windows开发人员来说，这个问题已经解决了——只要您更新一下对mklink的Windows理解并打开开发者模式。

在深入讨论下面的git技巧之前，先看看这个更现代的答案。

老系统:

我曾经问过这个完全相同的问题(不是在这里，只是在一般情况下)，最后得出了一个与OP的命题非常相似的解决方案。 我将发布我最终使用的解决方案。

但首先我将直接回答OP的3个问题:

问:“如果有的话，你认为这种方法有什么缺点?” 答:提议的解决方案确实有一些缺点，主要是增加了存储库污染的可能性，或者在它们处于“Windows符号链接”状态时意外添加重复文件。(关于这一点，请参阅下面的“限制”。)

问:“这个后检出脚本是可行的吗?例如，我可以递归找到虚拟的“符号链接”文件git创建? 答:是的，后检出脚本是可实现的!也许不能作为字面上的后git签出步骤，但是下面的解决方案已经很好地满足了我的需求，不需要字面上的后签出脚本。

问:“有人写过这样的剧本吗?” 答:是的!

解决方案:

我们的开发人员和OP的情况差不多:混合了Windows和类unix的主机、带有许多git符号链接的存储库和子模块，并且在MsysGit的发布版本中(目前)还没有本地支持在Windows主机上智能处理这些符号链接。

感谢Josh Lee指出git使用特殊文件模式120000提交符号链接。有了这些信息，就可以添加一些git别名，以便在Windows主机上创建和操作git符号链接。

Creating git symlinks on Windows git config --global alias.add-symlink '!'"$(cat <<'ETX' __git_add_symlink() { if [ $# -ne 2 ] || [ "$1" = "-h" ]; then printf '%b\n' \ 'usage: git add-symlink <source_file_or_dir> <target_symlink>\n' \ 'Create a symlink in a git repository on a Windows host.\n' \ 'Note: source MUST be a path relative to the location of target' [ "$1" = "-h" ] && return 0 || return 2 fi source_file_or_dir=${1#./} source_file_or_dir=${source_file_or_dir%/} target_symlink=${2#./} target_symlink=${target_symlink%/} target_symlink="${GIT_PREFIX}${target_symlink}" target_symlink=${target_symlink%/.} : "${target_symlink:=.}" if [ -d "$target_symlink" ]; then target_symlink="${target_symlink%/}/${source_file_or_dir##*/}" fi case "$target_symlink" in (*/*) target_dir=${target_symlink%/*} ;; (*) target_dir=$GIT_PREFIX ;; esac target_dir=$(cd "$target_dir" && pwd) if [ ! -e "${target_dir}/${source_file_or_dir}" ]; then printf 'error: git-add-symlink: %s: No such file or directory\n' \ "${target_dir}/${source_file_or_dir}" >&2 printf '(Source MUST be a path relative to the location of target!)\n' >&2 return 2 fi git update-index --add --cacheinfo 120000 \ "$(printf '%s' "$source_file_or_dir" | git hash-object -w --stdin)" \ "${target_symlink}" \ && git checkout -- "$target_symlink" \ && printf '%s -> %s\n' "${target_symlink#$GIT_PREFIX}" "$source_file_or_dir" \ || return $? } __git_add_symlink ETX )" Usage: git add-symlink <source_file_or_dir> <target_symlink>, where the argument corresponding to the source file or directory must take the form of a path relative to the target symlink. You can use this alias the same way you would normally use ln. E.g., the repository tree: dir/ dir/foo/ dir/foo/bar/ dir/foo/bar/baz (file containing "I am baz") dir/foo/bar/lnk_file (symlink to ../../../file) file (file containing "I am file") lnk_bar (symlink to dir/foo/bar/) Can be created on Windows as follows: git init mkdir -p dir/foo/bar/ echo "I am baz" > dir/foo/bar/baz echo "I am file" > file git add -A git commit -m "Add files" git add-symlink ../../../file dir/foo/bar/lnk_file git add-symlink dir/foo/bar/ lnk_bar git commit -m "Add symlinks" Replacing git symlinks with NTFS hardlinks+junctions git config --global alias.rm-symlinks '!'"$(cat <<'ETX' __git_rm_symlinks() { case "$1" in (-h) printf 'usage: git rm-symlinks [symlink] [symlink] [...]\n' return 0 esac ppid=$$ case $# in (0) git ls-files -s | grep -E '^120000' | cut -f2 ;; (*) printf '%s\n' "$@" ;; esac | while IFS= read -r symlink; do case "$symlink" in (*/*) symdir=${symlink%/*} ;; (*) symdir=. ;; esac git checkout -- "$symlink" src="${symdir}/$(cat "$symlink")" posix_to_dos_sed='s_^/\([A-Za-z]\)_\1:_;s_/_\\\\_g' doslnk=$(printf '%s\n' "$symlink" | sed "$posix_to_dos_sed") dossrc=$(printf '%s\n' "$src" | sed "$posix_to_dos_sed") if [ -f "$src" ]; then rm -f "$symlink" cmd //C mklink //H "$doslnk" "$dossrc" elif [ -d "$src" ]; then rm -f "$symlink" cmd //C mklink //J "$doslnk" "$dossrc" else printf 'error: git-rm-symlink: Not a valid source\n' >&2 printf '%s =/=> %s (%s =/=> %s)...\n' \ "$symlink" "$src" "$doslnk" "$dossrc" >&2 false fi || printf 'ESC[%d]: %d\n' "$ppid" "$?" git update-index --assume-unchanged "$symlink" done | awk ' BEGIN { status_code = 0 } /^ESC\['"$ppid"'\]: / { status_code = $2 ; next } { print } END { exit status_code } ' } __git_rm_symlinks ETX )" git config --global alias.rm-symlink '!git rm-symlinks' # for back-compat. Usage: git rm-symlinks [symlink] [symlink] [...] This alias can remove git symlinks one-by-one or all-at-once in one fell swoop. Symlinks will be replaced with NTFS hardlinks (in the case of files) or NTFS junctions (in the case of directories). The benefit of using hardlinks+junctions over "true" NTFS symlinks is that elevated UAC permissions are not required in order for them to be created. To remove symlinks from submodules, just use git's built-in support for iterating over them: git submodule foreach --recursive git rm-symlinks But, for every drastic action like this, a reversal is nice to have... Restoring git symlinks on Windows git config --global alias.checkout-symlinks '!'"$(cat <<'ETX' __git_checkout_symlinks() { case "$1" in (-h) printf 'usage: git checkout-symlinks [symlink] [symlink] [...]\n' return 0 esac case $# in (0) git ls-files -s | grep -E '^120000' | cut -f2 ;; (*) printf '%s\n' "$@" ;; esac | while IFS= read -r symlink; do git update-index --no-assume-unchanged "$symlink" rmdir "$symlink" >/dev/null 2>&1 git checkout -- "$symlink" printf 'Restored git symlink: %s -> %s\n' "$symlink" "$(cat "$symlink")" done } __git_checkout_symlinks ETX )" git config --global alias.co-symlinks '!git checkout-symlinks' Usage: git checkout-symlinks [symlink] [symlink] [...], which undoes git rm-symlinks, effectively restoring the repository to its natural state (except for your changes, which should stay intact). And for submodules: git submodule foreach --recursive git checkout-symlinks Limitations: Directories/files/symlinks with spaces in their paths should work. But tabs or newlines? YMMV… (By this I mean: don’t do that, because it will not work.) If yourself or others forget to git checkout-symlinks before doing something with potentially wide-sweeping consequences like git add -A, the local repository could end up in a polluted state. Using our "example repo" from before: echo "I am nuthafile" > dir/foo/bar/nuthafile echo "Updating file" >> file git add -A git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: dir/foo/bar/nuthafile # modified: file # deleted: lnk_bar # POLLUTION # new file: lnk_bar/baz # POLLUTION # new file: lnk_bar/lnk_file # POLLUTION # new file: lnk_bar/nuthafile # POLLUTION # Whoops... For this reason, it's nice to include these aliases as steps to perform for Windows users before-and-after building a project, rather than after checkout or before pushing. But each situation is different. These aliases have been useful enough for me that a true post-checkout solution hasn't been necessary.

引用:

http://git-scm.com/book/en/Git-Internals-Git-Objects

http://technet.microsoft.com/en-us/library/cc753194

最后更新:2019-03-13

POSIX compliance (well, except for those mklink calls, of course) — no more Bashisms! Directories and files with spaces in them are supported. Zero and non-zero exit status codes (for communicating success/failure of the requested command, respectively) are now properly preserved/returned. The add-symlink alias now works more like ln(1) and can be used from any directory in the repository, not just the repository’s root directory. The rm-symlink alias (singular) has been superseded by the rm-symlinks alias (plural), which now accepts multiple arguments (or no arguments at all, which finds all of the symlinks throughout the repository, as before) for selectively transforming git symlinks into NTFS hardlinks+junctions. The checkout-symlinks alias has also been updated to accept multiple arguments (or none at all, == everything) for selective reversal of the aforementioned transformations.

Final Note: While I did test loading and running these aliases using Bash 3.2 (and even 3.1) for those who may still be stuck on such ancient versions for any number of reasons, be aware that versions as old as these are notorious for their parser bugs. If you experience issues while trying to install any of these aliases, the first thing you should look into is upgrading your shell (for Bash, check the version with CTRL+X, CTRL+V). Alternatively, if you’re trying to install them by pasting them into your terminal emulator, you may have more luck pasting them into a file and sourcing it instead, e.g. as

. ./git-win-symlinks.sh

您可以通过查找模式为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创建符号链接