在Git 2.3.2+(2015年第一季度)中，还有一种情况下Git将不再遵循符号链接:参见由Junio C Hamano (gitster) (Git的主要维护者)提交e0d201b

适用:不要触及符号链接以外的文件

Because Git tracks symbolic links as symbolic links, a path that has a symbolic link in its leading part (e.g. path/to/dir/file, where path/to/dir is a symbolic link to somewhere else, be it inside or outside the working tree) can never appear in a patch that validly applies, unless the same patch first removes the symbolic link to allow a directory to be created there. Detect and reject such a patch. Similarly, when an input creates a symbolic link path/to/dir and then creates a file path/to/dir/file, we need to flag it as an error without actually creating path/to/dir symbolic link in the filesystem. Instead, for any patch in the input that leaves a path (i.e. a non deletion) in the result, we check all leading paths against the resulting tree that the patch would create by inspecting all the patches in the input and then the target of patch application (either the index or the working tree). This way, we: catch a mischief or a mistake to add a symbolic link path/to/dir and a file path/to/dir/file at the same time, while allowing a valid patch that removes a symbolic link path/to/dir and then adds a file path/to/dir/file.

这意味着，在这种情况下，错误消息不会是像“%s: patch不适用”这样的通用错误，而是更具体的错误:

affected file '%s' is beyond a symbolic link

这是一个预提交钩子，它用这些符号链接的内容替换索引中的符号链接blobs。

把它放在.git/hooks/pre-commit中，并使其可执行:

#!/bin/sh
# (replace "find ." with "find ./<path>" below, to work with only specific paths)

# (these lines are really all one line, on multiple lines for clarity)
# ...find symlinks which do not dereference to directories...
find . -type l -exec test '!' -d {} ';' -print -exec sh -c \
# ...remove the symlink blob, and add the content diff, to the index/cache
    'git rm --cached "$1"; diff -au /dev/null "$1" | git apply --cached -p1 -' \
# ...and call out to "sh".
    "process_links_to_nondir" {} ';'

# the end

笔记

我们尽可能多地使用POSIX兼容功能;然而，diff -a不符合POSIX，可能还有其他原因。

这段代码中可能有一些错误/错误，即使它经过了一些测试。

符号链接的转换可能很有用。链接到Git文件夹中，而不是脚本中的符号链接。

为什么不反过来创建符号链接呢?这意味着不是从Git存储库链接到应用程序目录，而是以相反的方式链接。

例如，假设我正在设置一个安装在~/application中的应用程序，它需要一个配置文件config.conf:

我将config.conf添加到Git存储库中，例如~/repos/application/config.conf。 然后我通过运行ln -s ~/repos/application/config.conf从~/application创建一个符号链接。

这种方法可能并不总是有效，但到目前为止对我来说效果很好。

嗯，mount -bind似乎对达尔文不起作用。

有人有什么诀窍吗?

(编辑)

好吧，我在Mac OS X上找到了答案，那就是做一个硬链接。只是这个API不是通过ln公开的，所以你必须用你自己的小程序来做这件事。以下是该程序的链接:

在Mac OS X中创建目录硬链接

享受吧!

@user252400建议的另一种实现是使用bwrap，这是一个小型setuid沙盒，可以在所有主要发行版中找到——通常默认安装。Bwrap允许你无需sudo就可以绑定挂载目录，并在git或shell退出时自动解除绑定。

假设你的开发过程不是很疯狂(见下文)，在一个私有的命名空间中启动bash，并在git目录下绑定外部目录:

bwrap --ro-bind / / \
      --bind {EXTERNAL-DIR} {MOUNTPOINT-IN-GIT-DIR} \
      --dev /dev \
      bash

然后做你通常做的所有事情，比如git添加、git提交等等。当你完成时，退出bash。干净简单。

注意:为了防止沙盒转义，bwrap不允许执行其他setuid二进制文件。详见man bwrap。