$ 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:/// part，则暗示——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 克隆 file:////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

and

$ 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 Fetch Error with UNC”。

注意，从2016年开始，和Windows Git打包的MingW-64 Git .exe，支持UNC路径。 (参见“msys、msys2和MinGW-64之间有什么关系?”)

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

参见Johannes Schindelin (dscho)的commit 9e9da23, commit 5440df4(2019年1月17日)。 资助人:Kim Gybels (Jeff-G) (由Junio C Hamano—gitster—在commit f5dd919中合并，2019年2月5日)

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

对象的UNC路径中两个反斜杠的第一个 形式\ \ \ myserver \文件夹存储库。Git被剥离。

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

mingw: special-case arguments to sh The MSYS2 runtime does its best to emulate the command-line wildcard expansion and de-quoting which would be performed by the calling Unix shell on Unix systems. Those Unix shell quoting rules differ from the quoting rules applying to Windows' cmd and Powershell, making it a little awkward to quote command-line parameters properly when spawning other processes. In particular, git.exe passes arguments to subprocesses that are not intended to be interpreted as wildcards, and if they contain backslashes, those are not to be interpreted as escape characters, e.g. when passing Windows paths. Note: this is only a problem when calling MSYS2 executables, not when calling MINGW executables such as git.exe. However, we do call MSYS2 executables frequently, most notably when setting the use_shell flag in the child_process structure. There is no elegant way to determine whether the .exe file to be executed is an MSYS2 program or a MINGW one. But since the use case of passing a command line through the shell is so prevalent, we need to work around this issue at least when executing sh.exe. Let's introduce an ugly, hard-coded test whether argv[0] is "sh", and whether it refers to the MSYS2 Bash, to determine whether we need to quote the arguments differently than usual. That still does not fix the issue completely, but at least it is something. Incidentally, this also fixes the problem where git clone \\server\repo failed due to incorrect handling of the backslashes when handing the path to the git-upload-pack process. Further, we need to take care to quote not only whitespace and backslashes, but also curly brackets. As aliases frequently go through the MSYS2 Bash, and as aliases frequently get parameters such as HEAD@{yesterday}, this is really important.

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

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

解决方案: repo克隆的地方打开。git文件夹和配置文件。

对于远程源url设置值:

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