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

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

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

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

注意:从Git 1.6.1开始，这个通知就已经过时了。Git过去是这样的，现在不再是这样了。

Git默认情况下尝试存储符号链接，而不是遵循它们(为了紧凑，这通常是人们想要的)。

但是，当符号链接是一个目录时，我意外地设法让它在符号链接之外添加文件。

例如:

  /foo/
  /foo/baz
  /bar/foo --> /foo
  /bar/foo/baz

通过做

 git add /bar/foo/baz

当我尝试时，它似乎起作用了。然而，这种行为在当时是我不想要的，所以我不能给你更多的信息。

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

有人有什么诀窍吗?

(编辑)

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

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

享受吧!

使用硬链接代替。这不同于软(符号)链接。包括git在内的所有程序都将该文件视为常规文件。注意，可以通过更改源或目标来修改内容。

macOS版本(10.13 High Sierra之前版本)

如果你已经安装了git和Xcode，安装hardlink。这是一个创建硬链接的微观工具。

要创建硬链接，只需:

hln source destination

macOS High Sierra更新

苹果文件系统支持目录硬链接吗? 苹果文件系统不支持目录硬链接。在macOS上从HFS+转换为APFS卷格式时，所有目录硬链接都转换为符号链接或别名。 来自APFS FAQ上developer.apple.com

关注https://github.com/selkhateeb/hardlink/issues/31了解未来的替代方案。

在Linux和其他Unix版本上

ln命令可以创建硬链接:

ln source destination

在Windows (Vista, 7,8，…)

使用mklink在Windows上创建一个连接:

mklink /j "source" "destination"

在macOS上(我有Mojave/ 10.14, git版本2.7.1)，使用bindfs。

酿造安装bindfs

cd / path / to / git_controlled_dir

mkdir local_copy_dir

bindfs </full/path/ source_dir> </full/path/ local_dir >

其他评论暗示了这一点，但在其他答案中没有明确提供。希望这能为大家节省一些时间。

在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