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

GIT clone repo across local file system in windows

提问by Jon

I am a complete Noob when it comes to GIT. I have been just taking my first steps over the last few days. I setup a repo on my laptop, pulled down the Trunk from an SVN project (had some issues with branches, not got them working), but all seems ok there.

说到 GIT，我是一个完整的菜鸟。在过去的几天里，我刚刚迈出了第一步。我在我的笔记本电脑上设置了一个 repo，从一个 SVN 项目中拉下 Trunk（分支有一些问题，没有让它们工作），但那里似乎一切正常。

I now want to be able to pull or push from the laptop to my main desktop. The reason being the laptop is handy on the train as I spend 2 hours a day travelling and can get some good work done. But my main machine at home is great for development. So I want to be able to push / pull from the laptop to the main computer when I get home. I thought the most simple way of doing this would be to just have the code folder shared out across the LAN and do:

我现在希望能够从笔记本电脑拉或推到我的主桌面。原因是笔记本电脑在火车上很方便，因为我每天花 2 小时旅行，可以完成一些很好的工作。但是我家里的主机很适合开发。所以我希望回家后能够从笔记本电脑推/拉到主电脑。我认为最简单的方法是让代码文件夹在 LAN 上共享，然后执行以下操作：

git clone file://192.168.10.51/code

unfortunately this doesn't seem to be working for me:

不幸的是，这似乎对我不起作用：

so I open a git bash cmd and type the above command, I am in C:\code (the shared folder for both machines) this is what I get back:

所以我打开一个 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

How can I share the repository between the two machines in the most simple of ways.

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

There will be other locations that will be official storage points and places where the other devs and CI server etc will pull from, this is just so that I can work on the same repo across two machines.

将有其他位置将成为官方存储点以及其他开发人员和 CI 服务器等将从中提取的位置，这只是为了让我可以在两台机器上处理同一个 repo。

As per Sebastian's suggestion I get the following:

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

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

**EDIT - ANSWER **

**编辑 - 答案**

Thanks to all that helped. I tried the mapping a drive and that worked so thought I would go back and retry without mapping. The final result was:

感谢所有帮助。我尝试了映射驱动器并且奏效了，所以我想我会回去重试而不映射。最终结果是：

git clone file://\\192.168.0.51\code

This worked great.

这很好用。

Thanks

谢谢

采纳答案by poke

You can specify the remote's URL by applying the UNCpath to the file protocol. This requires you to use four slashes:

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

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

For example, if your main machine has the IP 192.168.10.51and the computer name main, and it has a share named codewhich itself is a git repository, then both of the following commands should work equally:

例如，如果您的主机具有 IP 192.168.10.51和计算机名称main，并且它有一个名为codegit 存储库的共享，那么以下两个命令应该同样有效：

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

If the Git repository is in a subdirectory, simply append the path:

如果 Git 存储库位于子目录中，只需附加路径：

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

回答by jfs

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

The above command uses POSIX path notation for the directory with your git repository. For Windows it is (directory C:/path/to/repocontains .gitdirectory):

上面的命令使用 POSIX 路径表示法来表示 git 存储库的目录。对于 Windows，它是（目录C:/path/to/repo包含.git目录）：

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

The repository will be clone to C:\some\dir\my_project. If you omit file:///part then --localoption is implied.

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

回答by Talaat Safwat

the answer with the host name didn't work for me but this did :

主机名的答案对我不起作用，但这样做了：

git clone file:////home/git/repositories/MyProject.git/

git clone file:////home/git/repositories/MyProject.git/

回答by Mark F Guerra

I was successful in doing this using file://, but with one additional slash to denote an absolute path.

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

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

In my case I'm using Git on Cygwin for Windows, which you can see because of the /cygdrive/c part in my paths. With some tweaking to the path it should work with any git installation.

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

Adding a remote works the same way

添加遥控器的工作方式相同

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

回答by intuited

Maybe map the share as a network drive and then do

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

git clone Z:\

Mostly just a guess; I always do this stuff using ssh. Following that suggstion of course will mean that you'll need to have that drive mapped every time you push/pull to/from the laptop. I'm not sure how you rig up ssh to work under windows but if you're going to be doing this a lot it might be worth investigating.

大多只是猜测；我总是使用 ssh 来做这些事情。遵循该建议当然意味着您每次推/拉笔记本电脑时都需要映射该驱动器。我不确定您如何设置 ssh 以在 Windows 下工作，但如果您要经常这样做，则可能值得研究。

回答by bargar

Not sure if it was because of my git version (1.7.2) or what, but the approaches listed above using machine name and IP options were not working for me. An additional detail that may/may not be important is that the repo was a bare repo that I had initialized and pushed to from a different machine.

不确定是因为我的 git 版本（1.7.2）还是什么，但是上面列出的使用机器名称和 IP 选项的方法对我不起作用。一个可能/可能不重要的额外细节是，这个 repo 是一个我已经初始化并从另一台机器推送到的裸 repo。

I was trying to clone project1 as advised above with commands like:

我试图按照上面的建议使用以下命令克隆 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

What didwork for me was something simpler:

什么做的工作对我来说是更简单的东西：

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

Note - even though the repo being cloned from was bare, this did produce a 'normal' clone with all the actual code/image/resource files that I was hoping for (as opposed to the internals of the git repo).

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

回答by sidquanto

Either enter absolute paths or relative paths.

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

For example the first one below uses absolute paths :

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

(this is from inside the folder which contains the repository and the backup as subfolders. also remember that the backup folder is not modified if it already contains anything. and if it is not present, a new folder will be created )

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

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

The following uses relative paths :

以下使用相对路径：

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

回答by VonC

While UNC path is supported since Git 2.21 (Feb. 2019, see below), Git 2.24 (Q4 2019) will allow

虽然自 Git 2.21（2019 年 2 月，见下文）起支持 UNC 路径，但 Git 2.24（2019 年第四季度）将允许

git clone file://192.168.10.51/code

No more file:////xxx, 'file://' is enough to refer to an UNC path share.
See "Git Fetch Error with UNC".

没有更多file:////xxx，“ file://”足以指代 UNC 路径共享。
请参阅“使用 UNC 获取 Git 错误”。

---

---

Note, since 2016 and the MingW-64git.exepackaged with Git for Windows, an UNC path is supported.
(See "How are msys, msys2, and MinGW-64 related to each other?")

请注意，自 2016 年和与Git for Windows一起打包的MingW-64以来，支持 UNC 路径。 （参见“ msys、msys2 和 MinGW-64 之间的关系如何？”）git.exe

And with Git 2.21 (Feb. 2019), this support extends even in in an msys2shell (with quotes around the UNC path).

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

See commit 9e9da23, commit 5440df4(17 Jan 2019) by Johannes Schindelin (dscho).
Helped-by: Kim Gybels (Jeff-G).
^{(Merged by Junio C Hamano -- gitster--in commit f5dd919, 05 Feb 2019)}

请参阅Johannes Schindelin ( ) 的commit 9e9da23和commit 5440df4（2019 年 1 月 17 日）。 帮助者：Kim Gybels ( )。^{（由Junio C Hamano合并-- --在提交 f5dd919 中，2019 年 2 月 5 日）}dscho
Jeff-G
gitster

Before Git 2.21, due to a quirk in Git's method to spawn git-upload-pack, there is a problem when passing paths with backslashes in them: Git will force the command-line through the shell, which has different quoting semantics in Git for Windows (being an MSYS2 program) than regular Win32 executables such as git.exeitself.

在 Git 2.21 之前，由于 Git 的 spawn 方法的一个怪癖，git-upload-pack在传递带有反斜杠的路径时会出现问题：Git 将强制命令行通过 shell，它在 Git for Windows 中具有不同的引用语义（作为 MSYS2程序）而不是常规的 Win32 可执行文件，例如它git.exe本身。

The symptom is that the first of the two backslashes in UNC paths of the form \\myserver\folder\repository.gitis stripped off.

症状是表单的 UNC 路径中的两个反斜杠中的第一个\\myserver\folder\repository.git被剥离。

This is mitigated now:

现在可以缓解这种情况：

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.exepasses arguments to subprocesses that are notintended 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_shellflag in the child_process structure.

There is no elegant way to determine whether the .exefile 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\repofailed due to incorrect handling of the backslashes when handing the path to the git-upload-packprocess.

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.

mingw：特殊情况的参数 sh

MSYS2 运行时尽最大努力模拟命令行通配符扩展和取消引用，这将由 Unix 系统上的调用 Unix shell 执行。

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

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

注意：这只是调用 MSYS2 可执行文件时的问题，而不是调用 git.exe 等 MINGW 可执行文件时的问题。但是，我们确实经常调用 MSYS2 可执行文件，尤其是use_shell在 child_process 结构中设置标志时。

没有一种优雅的方法可以确定.exe要执行的文件是 MSYS2 程序还是 MINGW 程序。
但是由于通过 shell 传递命令行的用例非常普遍，我们需要至少在执行sh.exe.

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

这仍然不能完全解决问题，但至少它是一些东西。

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

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

See t/t5580-clone-push-unc.sh

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

回答by idanek

After clone, for me push wasn't working.

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

Solution: Where repo is cloned open .git folder and config file.

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

For remote origin url set value:

对于远程源 url 设置值：

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