网络共享文件夹中 GIT 存储库中的并发性

问题描述：

我想将裸 git 存储库存储在 (windows) 网络共享上。我使用 linux，并使用 CIFS 安装所述网络共享。我的同事使用 windows xp，并将网络共享自动安装（以某种方式从 ActiveDirectory 安装）为网络驱动器。

我想知道我是否可以在两台计算机上使用该 repo，而不会出现并发问题。

我已经测试过了，在我这边我可以成功克隆，但我担心如果我们同时访问同一个 repo（推送/拉取）可能会发生什么。

在 git FAQ 中有一个关于使用网络文件系统（以及 SMBFS 的一些问题）的参考，但我不确定网络/服务器/windows/linux 是否有任何文件锁定 - 我很确定没有。

那么，是否有人使用过网络共享上的 git repo，无需服务器，而且没有任何问题？

谢谢你，

亚历克斯

PS：我想避免使用 http 服务器（或 git-daemon），因为我无法访问具有共享的服务器。另外，我知道我们可以从一个服务器推送/拉取到另一个服务器，但出于备份原因，我们需要将代码/存储库放在共享中。

更新：

我担心的不是网络故障的可能性。即便如此，我们在本地也会有所需的分支，并且能够编译我们的源代码。

但是，我们通常提交得相当频繁，并且需要经常进行重新定基/合并。从我的角度来看，最好的选择是在共享上有一个中央存储库（这样备份就有了保证），我们都将从该存储库克隆，并使用它来进行重新定基。

但是，由于我们经常这样做，如果我们同时推送/拉取，我担心文件/存储库会损坏。通常，每次访问远程存储库时，我们都会互相大喊大叫:)，但最好通过计算机/网络来保护它。

并且，GIT 可能有一个内部机制来执行此操作（因为当您处理它时，有人可以将其推送到您的一个存储库），但我还没有发现任何确凿的证据。

更新 2：

共享驱动器上的 repo 将是一个裸repo，不包含工作副本。

解决方案 1：

Git 需要最少的文件锁定，我认为这是在网络文件系统上使用这种共享资源时出现问题的主要原因。它之所以能做到这一点，是因为 Git 存储库中的大多数文件（构成对象数据库的所有文件）都以内容摘要的形式命名，并且一旦创建就不可改变。因此，不会出现两个客户端尝试将同一文件用于不同内容的问题。

对象数据库的另一部分比较棘手——引用存储在“refs”目录下的文件中（或“packed-refs”），这些文件确实会发生变化：尽管文件refs/*很小，而且总是被重写而不是被编辑。在这种情况下，Git 将新的引用写入临时“.lock”文件，然后将其重命名为目标文件。如果文件系统尊重O_EXCL语义，那么这是安全的。即使不尊重语义，可能发生的最坏情况是竞争覆盖引用文件。虽然遇到这种情况会很烦人，但它不应该导致损坏：可能只是您推送到共享存储库，并且该推送看起来成功了，而实际上其他人的推送成功了。但这可以通过拉取（合并其他人的提交）并再次推送来解决。

总而言之，我认为 repo 损坏在这里不是什么大问题——确实，由于锁定问题，事情可能会出现一些问题，但 Git repo 的设计将最大限度地减少损害。

（免责声明：从理论上讲，这一切听起来都不错，但我没有对 repo 进行任何并发测试，并且只通过 NFS 而不是 CIFS 共享它们）

解决方案 2：

为什么要这么麻烦？Git 的设计初衷是分布式。只需在每台机器上建立一个存储库，然后使用发布和拉取机制在它们之间传播您的更改即可。

为了备份目的，请运行夜间任务将您的存储库复制到共享位置。

或者，在共享上分别创建一个存储库并从中执行工作，但将它们用作分布式存储库，以便彼此提取变更集。如果您使用此方法，则执行构建等操作的性能将降低，因为您将不断通过网络进行访问。

或者，在您自己的计算机上拥有分布式存储库，并运行定期任务将您的提交推送到共享上的存储库。

解决方案 3：

听起来你似乎更愿意使用集中式版本控制系统，这样备份查询就可以满足了。也许可以使用 xxx2git 进行本地工作。