Windows中跨本地文件系统的GIT克隆存储库

关于GIT，我是一个完整的菜鸟。最近几天，我一直只是迈出第一步。我在笔记本电脑上安装了一个存储库，从一个SVN项目中拉下了Trunk（分支有一些问题，但没有让它们正常工作），但是一切似乎都还可以。

现在，我希望能够从笔记本电脑拉动或推动到我的主台式机。原因是笔记本电脑在火车上很方便，因为我每天要花2个小时旅行，并且可以完成一些出色的工作。但是我在家的主要机器非常适合开发。因此，我希望能够在回家时将笔记本电脑从主机推/拉到主机。我认为最简单的方法是在LAN上共享代码文件夹，然后执行以下操作：

git clone file://192.168.10.51/code

不幸的是，这似乎不适用于我：

所以我打开git bash cmd并输入上面的命令，我在C：\ code（两台机器的共享文件夹）中，这就是我得到的：

Initialized empty Git repository in C:/code/code/.git/
fatal: 'C:/Program Files (x86)/Git/code' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

如何以最简单的方式在两台计算机之间共享存储库。

还有其他位置将成为官方存储点，其他开发人员和CI服务器等将从中获取这些位置，这是为了让我可以在两台计算机上的同一存储库中工作。

根据塞巴斯蒂安的建议，我得到以下信息：

C:\code>git clone --no-hardlinks file://192.168.10.51/code
Initialized empty Git repository in C:/code/code/.git/
fatal: 'C:/Program Files (x86)/Git/code' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

**编辑-答案**

感谢所有的帮助。我尝试了对驱动器进行映射，并且工作正常，以为我可以不进行映射就返回并重试。最终结果是：

git clone file://\\\\192.168.0.51\code

这很棒。

谢谢

您可以通过将UNC路径应用于文件协议来指定远程服务器的URL 。这要求您使用四个斜杠：

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

例如，如果您的主机具有IP 192.168.10.51和计算机名main，并且具有一个名为codegit本身的共享库，则以下两个命令应均能正常工作：

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 clone --no-hardlinks /path/to/repo

上面的命令将git仓库的目录使用POSIX路径表示法。对于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文件：////home/git/repositories/MyProject.git/

我使用file：//成功完成了此操作，但是使用了一个额外的斜杠来表示绝对路径。

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

就我而言，我在Windows的Cygwin上使用Git，由于路径中的/ cygdrive / c部分，您可以看到它。稍微调整一下路径即可在任何git安装中使用。

添加遥控器的方法相同

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

也许将共享映射为网络驱动器，然后执行

git clone Z:\

通常只是一个猜测；我总是使用ssh来做这些事情。当然，遵循该建议将意味着您每次将笔记本电脑推入/拉出笔记本电脑时都需要映射该驱动器。我不确定如何在Windows下安装ssh，但是如果您要进行很多操作，可能值得研究。

不知道这是因为我的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.

注意-即使要克隆的回购是裸露的，它也确实生成了一个“正常”的克隆，其中包含了我希望的所有实际代码/图像/资源文件（与git repo的内部相反）。

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

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

（这是从包含存储库和备份作为子文件夹的文件夹内部进行的。还请记住，如果备份文件夹已经包含任何内容，则不会对其进行修改。如果不存在，则会创建一个新文件夹）

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

以下使用相对路径：

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

自Git 2.21（2019年2月，请参见下文）以来支持UNC路径，但Git 2.24（2019年第四季度）将允许

git clone file://192.168.10.51/code

没有更多的file:////xxx' file://'足以引用UNC路径共享。
请参阅“ 使用UNC进行Git提取错误 ”。

请注意，自2016年以来，Git for Windows附带了MingW-64 ，因此支持UNC路径。 （请参阅“ msys，msys2和MinGW-64如何相互关联？ ”）git.exe

借助Git 2.21（2019年2月），此支持甚至在msys2 shell中也扩展了（在UNC路径周围带有引号）。

请参阅Johannes Schindelin（）的commit 9e9da23和commit 5440df4（2019年1月17日）。协作者 ：Kim Gybels（）。^{（通过合并JUNIOÇ滨野- -在提交f5dd919，2019年2月5日）}dscho
Jeff-G
gitster

在Git 2.21之前，由于Git的生成方法git-upload-pack存在怪异，因此在传递带有反斜杠的路径时会出现问题：Git将强制命令行通过外壳程序，该外壳程序在Windows的Git中具有不同的引用语义（即MSYS2）程序），而不是像常规Win32可执行文件一样git.exe。

的症状是，在第一形式的UNC路径的两个反斜杠的\\myserver\folder\repository.git被剥离。

现在可以缓解此问题：

mingw：的特殊情况参数 sh

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

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

特别是，git.exe将参数传递给不打算解释为通配符的子流程，并且如果它们包含反斜杠，则不应将其解释为转义符，例如，在传递Windows路径时。

注意：这仅是在调用MSYS2可执行文件时出现的问题，而不是在调用MINGW可执行文件（例如git.exe）时出现的问题。但是，我们确实经常调用MSYS2可执行文件，特别是use_shell在child_process结构中设置标志时。

没有优雅的方法来确定.exe要执行的文件是MSYS2程序还是MINGW程序。
但是，由于通过外壳传递命令行的用例非常普遍，因此至少在执行时，我们需要解决此问题sh.exe。

让我们介绍一个丑陋的，硬编码的测试，以确定是否argv[0]为“ sh”，以及它是否引用了MSYS2 Bash，以确定我们是否需要以不同于通常的方式引用参数。

那仍然不能完全解决问题，但至少可以解决。

顺便说一句，这还解决了git clone \\server\repo在将路径传递给git-upload-pack进程时由于对反斜杠的错误处理而导致失败的问题。

此外，我们不仅要引用空格和反斜杠，还要使用大括号。
由于别名经常经过MSYS2 Bash，并且别名经常获得诸如之类的参数HEAD@{yesterday}，因此这非常重要。

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

克隆后，对我而言，推送无效。

解决方案：在克隆仓库的位置打开.git文件夹和配置文件。

对于远程原始网址设置值：

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