在共享网络文件夹上设置 Git 时推送的文件丢失答案

【问题标题】：Pushed files missing when setting up Git on Shared Network folder在共享网络文件夹上设置 Git 时推送的文件丢失
【发布时间】：2019-12-23 03:50:31
【问题描述】：

我正在尝试使用共享网络驱动器作为主存储库来设置 git。

我在 cmd 上做了以下操作：

pushd //networkdrive/myrepo/
git init samplegitrepo --shared
popd
git clone //networkdrive/myrepo/samplegitrepo

我在C:/localfolder/samplegitrepo 中创建了一个新的示例文本文件。然后使用TortoiseGit，执行了add->commit->push，提示这些都成功了。

但是，当我检查//networkdrive/myrepo/samplegitrepo 时，我没有看到我提交的示例文本文件。我错过了什么吗？

【问题讨论】：

当您再次尝试克隆 repo（在单独的文件夹中）时，您是否看到示例文本文件？
@GinoMempin 是的，我可以在克隆到新文件夹时看到示例文本文件。有什么想法为什么？如果我在共享文件夹中看不到它，它实际保存在哪里？

标签： git shared-directory

【解决方案1】：

TL;DR：您可能希望将共享 Git 配置为将 receive.denyCurrentBranch 设置为 updateInstead。在执行之前，请确保您确切知道这意味着什么！您更有可能将共享存储库配置为 bare 存储库。另见What are the consequences of using receive.denyCurrentBranch in Git?

长篇

git init samplerepo 创建一个名为samplerepo 的新空目录，然后在该目录中创建一个新的空存储库，因此samplerepo 是新空存储库的工作树。这个新的空存储库没有提交，因此（还）没有分支。 samplerepo 目录将只包含一个子目录.git，用于正确保存存储库。

创建了这个空存储库，然后克隆它。克隆过程会给你一个关于克隆空存储库的警告，因为在使用空存储库时，各种事情往往有点奇怪。在任何情况下，这个克隆也没有分支，因为像 master 这样的分支名称只能通过包含一些现有的有效提交的哈希 ID 来存在。空存储库没有提交。

尽管缺少分支，但空的存储库仍然在一个分支上。它只是在一个不存在的分支上。这就是奇怪之处。

接下来，您在克隆的工作树中创建了一个文件，使用git add 将该文件复制到此克隆的索引中，然后运行git commit。这在克隆中创建了第一个提交，该提交现在是非空的。创建此提交允许分支 master 出现，它确实做到了。（如果您愿意，您现在可以创建无限数量的附加分支名称：所有必须，必然，识别这个存在的提交。）

最后，你告诉你的 Git 联系共享区域上的另一个 Git，//networkdrive/myrepo/samplegitrepo。¹ 你的 Git 将你所做的这个提交给了另一个 Git，Git 存储在该存储库 - 共享驱动器上的存储库。然后您的 Git 要求 Git 创建或更新其分支名称 master 以识别一个提交。确实如此。

在另一个 Git 中创建提交 对该 Git 的工作树没有影响。 这是 Git 存储库的正常行为：通过 git push 将新提交放入其中不会影响其工作树。事实上，一般来说，将新提交放入它已检出的分支中通常会完全拒绝。此处允许它的原因是它已签出的分支 - 它的 master - 不存在，原因与您的克隆的 master 最初不存在的原因相同。

现在分支确实存在，未来推送到master 的尝试将被拒绝，因为receive.denyCurrentBranch 未设置，这会导致与将其设置为@987654341 相同的行为@。在What are the consequences of using receive.denyCurrentBranch in Git?的各种答案中有很多讨论你应该阅读它。

¹更典型的是，您会通过一些https:// 或ssh:// URL 联系一个完全独立的主机。然后，另一台主机将有一种方法来验证您并决定是否允许您访问那里的 Git 存储库。在这种情况下，您自己的 Git 会启动第二个 Git 实例以在共享驱动器中工作。这使得 Git 可以像在与另一台机器交谈一样继续工作，即使它只是与在共享驱动器中运行的另一个自身副本交谈。您的操作系统会通过共享驱动器自动处理身份验证。

这就是--shared 变得重要的地方，如果您打算让其他机器上的其他用户让他们的操作系统负责共享。面向 Linux 的 Git --shared=true 或 --shared=group 设置（这是 --shared 默认设置的）取决于 Linux 样式的组权限。您正在显示各种 Windows-ish 路径，并且 Windows 权限通常与 Linux 非常不同，因此这可能无法实现您想要的。我不“做”Windows，所以不知道如何完成您想要的，但值得关注。

【讨论】：

感谢您的详细回复。给我一些光明。但是，我仍然没有在共享存储库中看到我的“推送”文件。我已经修改了denyCurrentBranch，这允许我推送，但在共享文件夹上仍然看不到更改。请帮忙
假设“共享文件夹”是指//networkdrive/myrepo/samplegitrepo 而不是//networkdrive/myrepo/samplegitrepo/.git，文件出现的唯一方法是让一些Git 执行git checkout in 那里。这就是设置updateInstead 应该做的事情，但也许有一个必须首先运行的初始化步骤（以在那里填写索引），在这种情况下，导航到//networkdrive/myrepo/samplegitrepo 并运行git checkout master 一次。
无论如何，我强烈建议反对尝试使用 Git 作为部署系统，这正是您在这里所做的。 Git 不是作为部署系统而设计的，而且做得很糟糕。