在谈到GIT时，我是一个完整的Noob。过去几天我一直在迈出第一步。我在我的笔记本电脑上设置了一个repo，从一个SVN项目中拉下了Trunk（有一些分支问题，没有让它们正常工作），但一切似乎都没问题。
我现在希望能够从笔记本电脑拉到或推送到我的主桌面。原因是笔记本电脑在火车上很方便，因为我每天花2个小时旅行，可以完成一些好的工作。但我家里的主机非常适合开发。因此，当我回到家时，我希望能够从笔记本电脑推/拉到主计算机。我认为最简单的方法就是让局域网中的代码文件夹共享，并执行：
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，并且它有一个名为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 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 file：////home/git/repositories/MyProject.git/
我使用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 clone Z:\
大多只是猜测;我总是使用ssh来做这些事情。以下结果当然意味着每次推/拉笔记本电脑时都需要映射该驱动器。我不确定你是如何装配ssh在windows下工作的，但是如果你要做很多这样的事情，可能值得调查一下。
不确定是不是因为我的git版本（1.7.2）或者是什么，但上面列出的使用机器名和IP选项的方法对我不起作用。可能/可能不重要的另一个细节是repo是我刚刚从另一台机器初始化并推送到的一个裸仓库。
我试图按照上面的建议克隆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/
请注意，自2016年起，MingW-64 git.exe与Git for Windows打包在一起，支持UNC路径。
（参见“How are msys, msys2, and MinGW-64 related to each other?”）
使用Git 2.21（2019年2月），这种支持甚至延伸到msys2 shell（在UNC路径周围引用）。
参见commit 9e9da23，commit 5440df4，Johannes Schindelin (dscho)（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本身。
症状是\\myserver\folder\repository.git形式的UNC路径中的两个反斜杠中的第一个被剥离。
这现在减轻了：
mingw：
sh的特例论证MSYS2运行时尽力模拟命令行通配符扩展和取消引用，这将由Unix系统上的调用Unix shell执行。
那些Unix shell引用规则与适用于Windows'cmd和Powershell的引用规则不同，这使得在生成其他进程时正确引用命令行参数有点尴尬。
特别是，
git.exe将参数传递给不打算被解释为通配符的子进程，如果它们包含反斜杠，则不应将这些参数解释为转义字符，例如传递Windows路径时。注意：这只是在调用MSYS2可执行文件时的问题，而不是在调用MITW可执行文件（如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}等参数，因此这非常重要。