如果我有本地伊奇维基在我的笔记本电脑上，我需要一个“存储库”目录（mywiki.git一个裸存储库）、一个“scrdir”（myiki一个 git 存储库）和一个生成的 html 文件所在的位置（“destdir”），以便从本地 Web 浏览器正确运行它。
但是，如果我还想在命令行上使用文本编辑器和 git，我需要设置第三个 git 存储库mywiki.local（“工作克隆”）。哪个推送到mywiki.git哪个又会触发一个post-update钩子推送到 scrdir 并重建 html 页面，如下图所示：
通过这种方法，我需要三我的笔记本电脑上几乎相同的目录只是为了运行一个 wiki，即它占用了三倍的磁盘空间，而不是一次。
这背后的原因是什么？
如果您只在一台机器上工作，是否有一种安全的方法来避免这种情况，将其减少到只有两个甚至更好的一个目录？
答案1
确实显得太过分了。可能只处理一个 git 存储库。这一切都取决于基础设施的能力ikiwiki（我对此一无所知）。
为什么
您希望存储库成为裸存储库的原因是因为非裸存储库几乎总是会签出分支。其他 git 存储库将不允许交付到在目标存储库上签出的分支（想象一下在分支上工作，推送发生在您的计算机上，并且文件在您的眼皮底下发生更改）。
您也许可以从“存储库”中进行工作，srcdir而不是克隆“存储库”。尽管如果您可以与 Web 端编辑同时修改文件，这可能会导致资源争用。此外，如果您手动推送并且推送也发生，它可能会变得混乱ikiwiki.cgi。它们ikiwiki可能会放入您不想在推送时运行的钩子。因此，我想他们建议您从“存储库”进行克隆。
Git 的一个特性
当您从本地计算机克隆 git 存储库时，git 会进行重大优化。如果您使用该--local选项（如果您这样做，则这是默认选项git clone /path/to/repo），它会使用它们共享的公共历史记录的硬链接，从而节省磁盘空间。以下是摘录git help clone：
--local, -l
When the repository to clone from is on a local machine,
this flag bypasses the normal "Git aware" transport
mechanism and clones the repository by making a copy of
HEAD and everything under objects and refs directories.
The files under .git/objects/ directory are hardlinked to
save space when possible.
多余的磁盘空间不在.git/objects目录中，而是在结帐本身中。如果这对您来说仍然太过分，那么您可能需要继续寻找其他解决方案。
结论
除非您对 的内部工作原理了解很多ikiwiki，否则我不会尝试规避他们推荐的设置方式。我会认为这是不安全的。如果您想要一个更好的答案，您可能想去一个更好的论坛，有更多关于 的知识ikiwiki。
当您意识到 git 执行内部 git 对象文件的硬链接时，额外使用的磁盘空间就不是什么问题了。
答案2
我已成功使用 ikiwiki 和 0+ 存储库。
0..2 是单用户，所以我还没有遇到冲突。 0..1 只是 ikiwiki 的一个实验。
这是我尝试过的：
- 0 个存储库 - 手动编译，
- 1 个存储库（工作目录 == srcdir），没有上游 - 手动编译，
- 2 个存储库（工作目录 == srcdir + 上游）
- 3+ 存储库（服务器上的上述 2 个 + NB 上的远程存储库）
对于 3+，我们将转向多用户，所以我预计它会更有趣。
我正在寻找与您相同的问题的答案，因此答案如下：
如果您直接编辑 ikiwiki srcdir，如果 web-ui 编辑同一个文件（或由其他用户推送到裸存储库），您将会遇到冲突。
如果您在 srcdir 中提交，冲突将由 web-ui 处理。
但任何未提交的更改到文件会迷路。
如果您不使用 Web 编辑功能，并且没有其他用户提交该存储库，那么您可以使用 2 个存储库。甚至 1 也可能有效。或者 1 使用远程存储库。
另外，我想在 srcdir 更新/重置之前编写一个插件来存储任何更改会很容易。