如果我有一个符号链接的文件或目录并将其提交到 Git 存储库,它会发生什么?
我假设它将它保留为符号链接,直到文件被删除,然后如果您从旧版本中拉回文件,它只会创建一个普通文件。
当我删除它引用的文件时它会做什么?它只是提交悬空链接吗?
.gitignore
将符号链接视为文件而非文件夹。
../..
。
git pull
创建一个文件而不是符号链接,请尝试以管理员身份运行您的 Git 客户端。
从 linux symlink manual(假设您在 Linux 中):
符号链接是一种特殊类型的文件,其内容是一个字符串,该字符串是另一个文件的路径名,即链接所指向的文件。 (可以使用 readlink(2) 读取符号链接的内容。)
因此,符号链接是一个文件,就像 README.md
或 Makefile
。 Git 只是将链接的内容(即,它链接到的文件系统对象的上述路径)存储在一个“blob”中,就像它存储任何其他文件一样。然后它将名称、模式和类型(包括它是符号链接的事实)存储在表示其包含目录的树对象中。
当您检出包含链接的树时,无论目标文件系统对象是否存在,它都会将该对象恢复为符号链接。
如果您删除符号链接引用的文件,它不会以任何方式影响 Git 控制的符号链接。你会有一个悬空的参考。如果需要,用户可以删除或更改链接以指向有效的内容。
您可以通过将符号链接添加到索引中来查看 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 add ./symlink
那么,添加了什么?
$ git ls-files -s ./symlink
120000 1596f9db1b9610f238b78dd168ae33faa2dec15c 0 symlink
哈希是对在对象存储中创建的打包对象的引用。如果您查看存储库根目录中的 .git/objects/15/96f9db1b9610f238b78dd168ae33faa2dec15c
,则可以检查此对象。 这是 Git 存储在存储库中的文件,您可以稍后签出。如果您检查此文件,您会发现它非常小。它不存储链接文件的内容。要确认这一点,请使用 git cat-file
打印打包存储库对象的内容:
$ git cat-file -p 1596f9db1b9610f238b78dd168ae33faa2dec15c
/path/referenced/by/symlink
(注意 120000
是 ls-files
输出中列出的模式。对于常规文件,它类似于 100644
。)
但是当你从存储库中检出这个对象并进入你的文件系统时,Git 会如何处理这个对象呢?这取决于 core.symlinks
配置。从 man git-config
:
core.symlinks 如果为 false,则符号链接将作为包含链接文本的小纯文件检出。
因此,使用存储库中的符号链接,在签出时,您可以得到一个包含完整文件系统路径引用的文本文件,或者是一个正确的符号链接,具体取决于 core.symlinks
配置的值。
无论哪种方式,符号链接引用的路径的内容都不会存储在存储库中(当然,除非引用的路径也在存储库中)。
/
为前缀,那么它将是绝对的,并且可能指向您的存储库之外。否则,它将是相对的。如果它是相对的并且指向您的存储库,那么它应该是可移植的,至少在类 Unix 系统之间是可移植的。
git cat-file -p
查看 git 存储对象的内容,因此如果您的符号链接的哈希是 c6e5580589892eb40407c74a825afaa6c9315787
,您可以执行 git cat-file -p c6e5580589892eb40407c74a825afaa6c9315787
并查看该包文件的内容,这只是一个符号链接
“编者注”:这篇文章可能包含过时的信息。请参阅关于自 1.6.1 以来 Git 更改的评论和此问题。
符号链接目录:
重要的是要注意当目录是软链接时会发生什么。任何带有更新的 Git 拉取都会删除链接并使其成为普通目录。这是我努力学习的方法。一些见解 here 和 here.
例子
前
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
特殊情况:当 "git checkout
"(man) 删除它正在检出的提交中不存在的路径时,没有注意不遵循符号链接,这有已使用 Git 2.32(2021 年第二季度)更正。
请参阅 Matheus Tavares (matheustavares
) 的 commit fab78a0、commit 462b4e8(2021 年 3 月 18 日)。
(由 Junio C Hamano -- gitster
-- 在 commit 9210c68 中合并,2021 年 3 月 30 日)
结帐:删除条目时不要遵循符号链接签名者:Matheus Tavares
在 1d718a5(“不要覆盖未跟踪的符号链接”,2011-02-20,Git v1.7.5-rc0 -- 合并),symlink.c:check_leading_path() 开始为 FL_ENOENT 和 FL_SYMLINK 返回不同的代码。但是它的调用者之一 unlink_entry() 并没有针对这种变化进行调整,因此它开始遵循要删除条目的前导路径上的符号链接。修复它并添加回归测试。而且因为我们不再尝试取消链接这些路径,所以我们也不会收到来自 remove_or_warn() 的警告。对于常规文件和符号链接的情况,首先该警告是否有用是值得怀疑的:unlink_entry() 删除了在我们正在检查的状态中不应再存在的跟踪路径。如果路径的前导目录被另一个文件替换,则意味着基本名称已经不存在,因此不需要警告。当然,我们在路径的目录名中留下了一个常规文件或符号链接,但是这个文件现在要么是未跟踪的(所以再一次,不需要警告),或者它将在此结帐的下一阶段被一个跟踪的文件替换
不定期副业成功案例分享
core.symlinks
配置变量设置为 false,并且符号链接将作为包含链接文本的小型纯文本文件检出。symlinks = false
弄乱它们。