Git如何处理符号链接？

Question

如果我有一个符号链接的文件或目录,我将它提交到Git存储库,它会发生什么？

我会假设它将它作为符号链接留下,直到文件被删除,然后如果你从旧版本拉回文件它只是创建一个普通文件.

当我删除它引用的文件时它会怎么做？它只是提交悬空链接吗？

Answer 1

Git只是将链接的内容(即它链接到的文件系统对象的路径)存储在'blob'中,就像它对普通文件一样.然后,它在表示其包含目录的树对象中存储名称,模式和类型(包括它是符号链接的事实).

签出包含链接的树时,无论目标文件系统对象是否存在,它都会将对象还原为符号链接.

如果删除符号链接引用的文件,则不会以任何方式影响Git控制的符号链接.你将有一个悬空参考.如果需要,用户可以删除或更改链接以指向有效的内容.

Answer 2

TL; DR:符号链接引用的数据不存储在存储库中.

您可以通过查看将文件添加到索引时的功能来了解Git对文件执行的操作.索引就像预先提交一样.提交索引后,您可以使用git checkout将索引中的所有内容返回到工作目录中.那么,当您向索引添加符号链接时,Git会做什么？

首先,要找出一个符号链接:

$ ln -s /path/referenced/by/symlink symlink

Git还不知道这个文件.git ls-files让你检查你的索引(-s打印stat类似输出):

$ git ls-files -s ./symlink
[nothing]

现在,通过将符号链接的内容添加到索引,将其添加到Git对象库中.将文件添加到索引时,Git将其内容存储在Git对象库中.

$ git add ./symlink

那么,添加了什么？

$ git ls-files -s ./symlink
120000 1596f9db1b9610f238b78dd168ae33faa2dec15c 0       symlink

哈希是对在Git对象库中创建的压缩对象的引用.如果查看.git/objects/15/96f9db1b9610f238b78dd168ae33faa2dec15c存储库的根目录,则可以检查此对象.这个文件是Git存储的,以及在添加和提交符号链接时可以从存储库中检出的内容.如果你检查这个文件,你会发现它非常小.它不存储链接文件的内容.

(注意输出中120000列出的模式ls-files.它类似于100644常规文件.)

但是当你从存储库和文件系统中检查出来时,Git会对这个对象做些什么呢？这取决于core.symlinks配置.来自man git-config:

core.symlinks

如果为false,则将符号链接签出为包含链接文本的小型纯文本.

因此,通过存储库中的符号链接,在结帐时,您可以获得一个文本文件,其中包含对完整文件系统路径的引用,或者是一个正确的符号链接,具体取决于core.symlinks配置的值.

无论哪种方式,符号链接引用的数据都不会存储在存储库中.

Answer 3

"编辑"注:此帖可能包含过时的信息.请参阅自1.6.1以来关于Git变化的评论和这个问题.

符号链接目录:

重要的是要注意当存在软链接的目录时会发生什么.任何带有更新的Git pull都会删除链接并使其成为普通目录.这就是我学到的难点.这里和这里的一些见解.

例

之前

 ls -l
 lrwxrwxrwx 1 admin adm   29 Sep 30 15:28 src/somedir -> /mnt/somedir

git add/commit/push

It remains the same

之后git pull发现了一些更新

 drwxrwsr-x 2 admin adm 4096 Oct  2 05:54 src/somedir

Answer 4

特殊情况：当“ git checkout” ^（man）删除它正在签出的提交中不存在的路径时，它不够小心，没有遵循符号链接，这一问题已在 Git 2.32（2021 年第 2 季度）中得到纠正。

请参阅Matheus Tavares的提交 fab78a0和提交 462b4e8（2021 年 3 月 18 日） ( )。^{（由Junio C Hamano 合并 -- --在提交 9210c68中，2021 年 3 月 30 日）}matheustavares
gitster

checkout：删除条目时不要遵循符号链接

^{签署人：马修斯·塔瓦雷斯}

在1d718a5（“不要覆盖未跟踪的符号链接”，2011-02-20，Git v1.7.5-rc0 - merge），symlink.c:check_leading_path() 开始为FL_ENOENT和返回不同的代码FL_SYMLINK。
但它的调用者之一unlink_entry()没有针对这一更改进行调整，因此它开始遵循要删除条目的主要路径上的符号链接。
解决这个问题并添加回归测试。

而且因为我们不再尝试取消链接此类路径，所以我们也不会收到来自 的警告remove_or_warn()。

对于常规文件和符号链接情况，警告一开始是否有用是值得怀疑的：unlink_entry()删除不应再出现在我们正在检查的状态中的跟踪路径。
如果路径的前导目录被另一个文件替换，则意味着基本名称已经不存在，因此不需要警告。
当然，我们在路径的目录名中留下了一个常规文件或符号链接，但该文件现在要么未被跟踪（所以再次，无需警告），要么在结帐的下一阶段它将被跟踪文件替换