我建议您不要在存储库中使用符号链接。将实际内容存储在存储库中，然后在存储库外放置指向内容的符号链接。

因此，假设您正在使用一个存储库来比较在类unix系统上托管站点与在Windows上托管站点。将内容存储在您的存储库中，例如/httpRepoContent和c:\httpRepoContent，这是通过Git、SVN等同步的文件夹。

然后，替换你的web服务器的内容文件夹(/var/www和c:\程序文件\web server\www{名称并不重要，如果你必须编辑})，用一个符号链接到你的存储库中的内容。web服务器将看到内容实际上是在“正确”的位置，但你可以使用你的源代码控制。

但是，如果您需要在存储库中使用符号链接，您将需要研究一些类似于前/后提交脚本的东西。我知道您可以使用它们来做一些事情，例如通过格式化程序解析代码文件，因此应该可以在平台之间转换符号链接。

如果有人知道一个好地方可以学习如何为常见的源代码控制、SVN、Git和MG执行这些脚本，那么请添加评论。

请注意更新

对于大多数受困于符号链接和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

因此，自从发布了很多这些答案以来，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

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

简单的回答:如果您可以启用开发人员模式，它们现在得到了很好的支持。

来自Windows 10的Symlinks !：

Now in Windows 10 Creators Update, a user (with admin rights) can first enable Developer Mode, and then any user on the machine can run the mklink command without elevating a command-line console. What drove this change? The availability and use of symlinks is a big deal to modern developers: Many popular development tools like git and package managers like npm recognize and persist symlinks when creating repos or packages, respectively. When those repos or packages are then restored elsewhere, the symlinks are also restored, ensuring disk space (and the user’s time) isn’t wasted.

“创建者更新”的所有其他公告很容易被忽略，但如果启用了开发人员模式，则可以在没有提升权限的情况下创建符号链接。您可能必须重新安装Git并确保启用了符号链接支持，因为默认情况下并没有启用符号链接支持。

2020+ TL;DR答案

在Windows 10/11中启用“开发人员模式”——赋予mklink权限 确保符号链接在git中启用(至少)其中之一 系统设置:安装msysgit时勾选复选框 全局设置:git配置——Global core。符号链接的真实 本地设置:git config core。符号链接的真实

注意，git在Windows上对符号链接的支持相对较新。 有一些错误仍然影响一些git客户端。 值得注意的是，由于libgit2中的(固定的)回归，在一些程序中带有相对(..)路径的符号链接被破坏了。 例如，GitKraken会受到影响，因为他们正在等待nodegit从v0更新libgit2。X(回归到v1)x(固定)。

重新创建缺失/损坏的符号链接

使用这些(越来越强大和“危险”)选项之一的多个git客户机已经报告了不同程度的成功

Checkout: git Checkout——path/to/symlink 恢复(从git v2.23.0开始):git Restore——path/to/symlink 切换分支(离开和返回) 硬复位:git复位-硬 删除本地存储库后重新克隆

故障排除

Git配置——show-scope——show-origin core。Symlinks将显示设置的级别(又名“作用域”)，保存设置的配置文件(又名“origin”)所在的位置，以及设置的当前值。“本地”配置很可能会覆盖“全局”或“系统”设置。Git配置——取消核心设置。Symlinks将清除一个“本地”设置，允许更高级别的设置生效。

我建议您不要在存储库中使用符号链接。将实际内容存储在存储库中，然后在存储库外放置指向内容的符号链接。

因此，假设您正在使用一个存储库来比较在类unix系统上托管站点与在Windows上托管站点。将内容存储在您的存储库中，例如/httpRepoContent和c:\httpRepoContent，这是通过Git、SVN等同步的文件夹。

然后，替换你的web服务器的内容文件夹(/var/www和c:\程序文件\web server\www{名称并不重要，如果你必须编辑})，用一个符号链接到你的存储库中的内容。web服务器将看到内容实际上是在“正确”的位置，但你可以使用你的源代码控制。

但是，如果您需要在存储库中使用符号链接，您将需要研究一些类似于前/后提交脚本的东西。我知道您可以使用它们来做一些事情，例如通过格式化程序解析代码文件，因此应该可以在平台之间转换符号链接。

如果有人知道一个好地方可以学习如何为常见的源代码控制、SVN、Git和MG执行这些脚本，那么请添加评论。