GIT克隆在windows中跨本地文件系统回购

小开

$ git clone --no-hardlinks /path/to/repo

上面的命令使用POSIX路径符号表示git存储库的目录。对于Windows，它是(目录C:/path/to/repo包含.git目录):

C:\some\dir\> git clone --local file:///C:/path/to/repo my_project

存储库将被克隆到C:\some\dir\my_project。如果省略file:///部分，则隐含--local选项。

小开

也许可以将共享映射为网络驱动器，然后这样做

git clone Z:\

大部分只是猜测;我总是用ssh来做这些事。按照这个建议，当然意味着你每次推/拉到笔记本电脑/从笔记本电脑出来时都需要映射这个驱动器。我不确定如何在windows下安装ssh，但如果您要经常这样做，可能值得研究一下。

小开

最佳答案

您可以通过将UNC路径应用到文件协议来指定远程的URL。这需要你使用四个斜杠:

git clone file:////<host>/<share>/<path>

例如，如果你的主机的IP地址是192.168.10.51，计算机名是main，并且它有一个名为code的共享，它本身是一个git存储库，那么下面的两个命令应该同样有效:

git clone file:////main/code
git clone file:////192.168.10.51/code

如果Git存储库在子目录中，只需追加路径:

git clone file:////main/code/project-repository
git clone file:////192.168.10.51/code/project-repository

小开

主机名的答案不适合我但这是:

git克隆文件:////home/git/repositories/MyProject.git/

小开

不确定是因为我的git版本(1.7.2)或其他原因，但上面列出的使用机器名和IP选项的方法对我不起作用。另外一个可能重要也可能不重要的细节是，这个回购是一个我已经初始化并从另一台机器推到的裸回购。

我试图克隆project1如上所述，使用如下命令:

$ git clone file:////<IP_ADDRESS>/home/user/git/project1
Cloning into project1...
fatal: '//<IP_ADDRESS>/home/user/git/project1' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

而且

$ git clone file:////<MACHINE_NAME>/home/user/git/project1
Cloning into project1...
fatal: '//<MACHINE_NAME>/home/user/git/project1' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

做了对我的工作更简单:

$ git clone ../git/project1
Cloning into project1...
done.

注意-即使被克隆的repo是裸露的，这确实产生了一个“正常”的克隆，所有实际的代码/图像/资源文件，我希望(而不是git repo的内部)。

小开

输入绝对路径或相对路径。

例如，下面的第一个使用绝对路径:

(这是在包含作为子文件夹的存储库和备份的文件夹中。还要记住，如果备份文件夹已经包含任何内容，则不会修改备份文件夹。如果它不存在，将创建一个新文件夹)

~/git$ git clone --no-hardlinks ~/git/git_test1/   ~/git/bkp_repos/

下面使用相对路径:

~/git$ git clone --no-hardlinks git_test1/   bkp_repos2/

小开

我使用file://成功地做到了这一点，但是使用了一个额外的斜杠来表示绝对路径。

git clone file:///cygdrive/c/path/to/repository/

在我的例子中，我在Cygwin for Windows上使用Git，你可以看到，因为我的路径中有/cygdrive/c部分。通过对路径进行一些调整，它应该适用于任何git安装。

添加远程的工作方式相同

git remote add remotename file:///cygdrive/c/path/to/repository/

小开

虽然从Git 2.21(2019年2月，见下文)开始支持UNC路径，但Git 2.24(2019年第四季度)将允许

git clone file://192.168.10.51/code

不再有file:////xxx， ` file://'足以引用UNC路径共享看到“Git获取错误与UNC”。< / p >

注意，自2016年起，mingw - 64 git.exe与Git for Windows打包，支持UNC路径 (参见“msys、msys2和MinGW-64的关系是什么?”)< / p >

在Git 2.21(2019年2月)中，这种支持甚至扩展到msys2 shell中(在UNC路径周围加上引号)。

参见提交9 e9da23，提交5440年df4 (17 Jan 2019) by 约翰内斯·辛德林(dscho) 得益于:Kim Gybels (Jeff-G)。< br > ^{(由Junio C Hamano—gitster— in 提交f5dd919合并，05 Feb 2019)}

在Git 2.21之前，由于Git生成git-upload-pack的方法中有一个怪癖，有一个当传递带有反斜杠的路径时，Git会强制命令行，在shell中有不同的引用语义 Git for Windows(是一个MSYS2程序)而不是常规的Win32可执行文件例如git.exe本身

异常现象:命令的UNC路径中两个反斜杠的第一个 form \\myserver\folder\repository.git是脱光衣服.

现在这个问题得到了缓解:

mingw: sh的特殊情况参数

MSYS2运行时尽力模拟命令行通配符展开和反引用，这将由Unix系统上的调用Unix shell执行。

这些Unix shell的引用规则与应用于Windows cmd和Powershell的引用规则不同，这使得在生成其他进程时正确引用命令行参数有点尴尬。

特别地，git.exe将参数传递给打算解释为通配符的不子进程，如果它们包含反斜杠，则它们不会被解释为转义字符，例如在传递Windows路径时。

注意:这只是在调用MSYS2可执行文件时出现的问题，而不是在调用MINGW可执行文件(如git.exe)时出现的问题。然而，我们经常调用MSYS2可执行文件，尤其是在child_process结构中设置use_shell标志时。
没有优雅的方法来确定将要执行的.exe文件是MSYS2程序还是MINGW程序但是由于通过shell传递命令行的用例非常普遍，我们至少在执行sh.exe时需要解决这个问题让我们引入一个丑陋的硬编码测试，argv[0]是否为"sh"，以及它是否指的是MSYS2 Bash，以确定我们是否需要
.
.
这仍然没有完全解决问题，但至少它是某种东西。

顺便说一句，这也修复了git clone \\server\repo在将路径传递给git-upload-pack进程时由于反斜杠处理错误而失败的问题。
此外，我们不仅需要注意引号中的空格和反斜杠，还需要注意花括号由于别名经常通过MSYS2 Bash，并且别名经常获得诸如HEAD@{yesterday}之类的参数，这是非常重要的

看到t/t5580-clone-push-unc.sh

小开

克隆之后，对我来说，推不起作用。

< p >解决方案: 在哪里克隆的回购打开。git文件夹和配置文件。

对于远程源url设置值:

[remote "origin"]
url = file:///C:/Documentation/git_server/kurmisoftware

GIT克隆在windows中跨本地文件系统回购

输入绝对路径或相对路径。

mingw: sh的特殊情况参数

mingw: `sh`的特殊情况参数