Windows 上的 Git，它是真正的分布式吗？
我刚刚开始在 Windows 平台上使用 git。我安装了 mysygit 并禁止 很少有问题 我很好地离开了。
但是，我一定错过了一些东西，因为我不明白不同 Windows 机器上的两个 msysgit 客户端如何直接相互推送和拉取？
我是一个完全的 Linux 菜鸟，但我想我可以看到 ssh 东西允许在 Linux 上分发。然而，msysgit 客户端似乎只是 Windows cmd 提示符中的附加命令，并且没有 Windows 服务元素。
如果我尝试 git clone 'MyMatesPc' 谁将在另一端监听此请求？
我可以看到，如果您有一台在 Linux（或 cygwin）上运行 git 的“中央”服务器，您可以通过将提交从一台机器推送到“中央”存储库，然后将它们拉到另一台机器上来共享提交。
这实际上意味着您必须使用中央服务器。
我对此没有任何问题，但想检查一下我是否遗漏了任何东西！
I am just starting out with git on the Windows platform. I have mysygit installed and bar a few hiccups I am 'git'ing away nicely.
However, I must be missing something because I don't understand how two msysgit clients on different Windows machines can push and pull to each other directly?
I am a complete linux noob but I think I can see that the ssh thing allows distribution on linux. However, the msysgit client appears just to be additional commands in the windows cmd prompt and there is no windows service element.
If I try git clone 'MyMatesPc' who is going to be listening to this request at the other end?
I can see that if you have a 'central' server running git on linux (or cygwin), you can share commits by pushing them onto the 'central' repo from one machine, then pulling them down onto another.
This effectively means that you are having to use a central server.
I don't have a problem with this, but wanted to check that I am not missing anything!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您可以使用本地协议：一个简单的共享路径足以让同一 LAN 上两台 PC 上的两个 Git 存储库相互推送/拉取。
（在这种情况下）不需要“中央”服务器。
正如 Noel Kennedy 在评论中指出的那样，他必须在执行之前在本地将驱动器号映射到远程存储库：
git 克隆文件:///z。这是最安全的路径，因为 UNC 路径并不总是受支持对于某些版本的 msysgit。
不过，您可以对最新的 msysgit 版本使用 UNC 路径，就像在 Git bash 会话中一样：（
注意“
/”而不是 Windows '\')在 DOS 会话中，添加
mingw/bin路径后，它也可能起作用（即使用 UNC 路径而不是映射驱动器）更新 2014 年 8 月 ( 4 年后），Git 2.1
Commit c2369bd，作者：Eric Sunshine 和 Cezary Zawadka (
czawadka) 表示现在可以使用更简单的 UNC 路径：Windows：允许对 git 存储库使用 UNC 路径
所以现在应该可以了：
You can use the local protocol: a simple shared path is enough for two Git repositories on two PC on the same LAN to push/pull from each other.
No need (in this case) for a "central" server.
As Noel Kennedy points out in the comments, he had to locally map a drive letter to the remote repo before executing:
git clone file:///z.That is the safest path, since UNC paths are not always supported with some versions of msysgit.
You can use UNC paths with recent msysgit versions though, like in a Git bash session:
(note the '
/' instead of the Windows '\')In a DOS session, after adding the
mingw/binpath, it might work too (i.e. using an UNC path instead of a mapped drive)Update August 2014 (4 years later), Git 2.1
Commit c2369bd by Eric Sunshine and Cezary Zawadka (
czawadka) means a simpler UNC path now work:Windows: allow using UNC path for git repository
So this should now work:
这是关于使用 git 的（众多）开发工作流程的一个非常常见的误解，与 msysgit 问题无关。
Git 是分布式开发，因为没有任何存储库具有任何特定的设计或结构，使其比任何其他存储库更具权威性 - 您可以在本地存储库上执行任何与中央存储库相同的操作，从这个角度来看，它们都是平等的。
例如，在 Linux 内核中，有数百个不同的公共存储库：通常 Linus 被认为是权威的，kernel.org 上的版本是从他的树上剪下来的，但是许多人或项目使用或维护其他树（ “分叉”，尽管这个术语有一定的含义），并且由于 git 对此的支持，在跟踪 Linus 树（或任何其他树 - 现在看到模式了吗？）中发生的开发时几乎没有阻抗不匹配或开销。
许多项目都使用中央存储库，因为这是一种易于理解的协作模型，或者因为它适合现有的持续集成设置 - 并且 git 同样适合这种开发风格 - 但这是一个工作流程决策，而不是强制要求（甚至受到 git 本身的青睐）。
就 msysgit 或 Cygwin 而言，通过它们使用 ssh 应该没有问题，而且还有 PuTTy 作为使用 SSH 协议的本机 Windows 客户端 - 它绝不特定于 UNIX 主机。使用本机 git 协议或 HTTP 来拉取也很容易（推送是另一个问题）。 （正如 VonC 所说，你也可以从本地存储库中提取数据，所以如果你有网络/Samba 共享或其他任何东西，它与 git 都是一样的）。
This is a pretty common misconception about (one of the many) development workflows using git, independent of the msysgit issue.
Git is distributed development in that no repository has any particular design or structure that makes it any more authoritative than any other - you can do anything you would do with a central repository on your local one, and from that perspective they are all on equal footing.
For example in the Linux kernel, there are hundreds of different, public repositories: generally Linus' is regarded as the authoritative one, and the releases on kernel.org are cut from his tree, but many people or projects use or maintain other trees ("forks", though that term has certain connotations), and because of git's support for this there is very little impedance mismatch or overhead in tracking the development that happens in Linus' tree (or any other tree - seeing the pattern now?).
Many projects use a central repository, since that's a well-understood model for collaboration, or because it fits in an existing continuous integration setup - and git is just as suited for this style of development - but this is a workflow decision, not one mandated (or even favored) by git itself.
As far as msysgit or Cygwin are concerned, you should have no problem using ssh through those, and there's also PuTTy as a native Windows client for using the SSH protocol - its by no means specific to UNIX hosts. It's also easy to use the native git protocol, or HTTP to pull as well (pushing is another issue). (As VonC said, you can pull from local repositories as well, so if you have a network/Samba share or whatever its all the same to git).
有很多方法可以处理克隆存储库，具体取决于两台机器之间的连接性。如果您想避免在 Windows 上建立 Git 服务器的麻烦，那么您可以将 Git 存储库存储在共享目录上，并使用
file:协议访问它们。根据您使用的 Git 客户端，您可能需要将该共享目录映射到驱动器号。There are a lot of ways to handle cloning repositories, depending upon the connectivity between two machines. If you want to avoid the hassle of standing up a Git server on Windows, then you could store the Git repositories on a shared directory, and access them using the
file:protocol. Depending upon the Git client you use, you may need to map that shared directory to a drive letter.恕我直言，win32 上尚未很好地支持 git 服务器组件。
没有什么说你不能通过电子邮件从人们那里获取补丁并将它们应用到你的存储库中。
此外，分布式版本控制的要点是，虽然您可以选择与远程存储库同步，但您不必这样做。没有什么可以阻止您在世界任何地方（包括海洋中部或偏远的沙漠）在断开连接的 PC 上使用 git。
git server components are not yet well supported on win32, imho.
Nothing saying you can't take patches from people via email and apply them to your repository.
Also, the point of distributed version control is that while you MAY choose to sync with a remote repository, you don't have to. Nothing is stopping you from using git on your disconnected PC anywhere in the world (including the middle of the ocean or a remote desert).