我们的开发人员混合使用Windows和基于unix的操作系统。因此,在Unix机器上创建的符号链接成为Windows开发人员的一个问题。在Windows (MSysGit)中,符号链接被转换为一个文本文件,并带有它所指向的文件的路径。相反,我想将符号链接转换为实际的Windows符号链接。
我对此的(更新的)解决方案是:
编写一个检出后脚本,递归地查找“符号链接”文本文件。
将它们替换为Windows符号链接(使用mklink),具有与虚拟“symbolic link”相同的名称和扩展名
通过在文件.git/info/exclude中添加一个条目来忽略这些Windows符号链接
我还没有实现这个方法,但我相信这是解决这个问题的可靠方法。
如果有的话,你认为这种方法有什么缺点?
这个后签出脚本是可实现的吗?也就是说,我能递归地找到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执行这些脚本,那么请添加评论。