致命：不是 git 存储库：'.'

TL;DR：你可能想要unset GIT_DIR在你的脚本的前面（好吧，但是 Haskell 拼写了这个操作）。

这里的问题是，虽然/tmp/A 是一个合理的 Git 存储库，但实际的存储库本身位于.git子目录中。也就是说，/tmp/A/是工作树，/tmp/A/.git是正确的存储库。

在正常操作中，我们运行，例如，或从我们的工作树运行。工作树包含目录，或者在某些情况下，¹一个文件。顶级命令检查，找到它，然后说啊哈，存储库是. 或者，它没有找到，所以它向上看一层——例如，从它爬上一层到它自己，并在那里检查。这重复直到某种停止点。²git subcommand arguments ...git statusgit commit -m message.git.gitgit.git./.git.git/tmp/A/tmp.git

在所有情况下，此搜索过程必须要么成功停止（通过找到正确的存储库），要么随着消息而终止。现在是关键的，隐藏在明显的视线中的秘密：此时，顶级命令设置一个名为的环境变量，以包含实际存储库的路径名。然后它运行用于定位存储库的子命令。在我们正常使用情况下，我们都在和包含目录，这台以和子命令所有工作。git subcommandfatal: Not a git repository ...gitGIT_DIR$GIT_DIR/tmp/A/tmp/A.git$GIT_DIR/tmp/A/.git

但在你的情况下，$GIT_DIR已经设置好了。特别地，它被设置为.。所以现在顶级git命令停止搜索。它只是验证它$GIT_DIR是有效的并命名一个 Git 存储库，或者以fatal错误消息结束。由于/tmp/A 不是存储库 - 它确实是/tmp/A/.git- 这会导致问题。

取消设置环境变量会重新打开搜索，从而解决问题。您也可以--git-dir用作参数，或在$GIT_DIR. 请注意，相同的规则适用于$GIT_WORK_TREE:--work-tree参数集$GIT_WORK_TREE，如果你不使用它并且$GIT_WORK_TREE 没有设置，前端git命令使用它爬上文件系统树到一个.git目录或文件代码来找到你的工作树。所以，如果$GIT_DIR还是$GIT_WORK_TREE 被当您运行设置，Git会遵守的，除非你覆盖它们和/或。git subcommand--git-dir--work-tree

钩子总是$GIT_DIR固定的。他们可能也可能没有$GIT_WORK_TREE设置。它们中的大多数运行在工作树的顶层，但是，正如githooks 文档所指出的，pre-receive, update, post-receive, post-update, 和push-to-checkout都运行在$GIT_DIR.

¹该.git-as-A-文件伎俩被两个子模块，并添加工作树，在现代的Git。Git 1.7 和早期的 1.8 留下带有嵌入式.git目录的子模块，并且不支持添加的工作树。

²明显的停止点是到达/时，此时无处可攀。然而，默认情况下，Git 是小心的，至少在 Unix 和类 Unix 系统上，以避免爬过挂载点。挂载点允许您将不同的文件系统层和/或存储池嫁接到单个树状结构的层次结构中。/tmp例如，通常它本身可能是一个内存文件系统，并且大型系统可能会将“系统存储”（/等等）与“用户存储”（/home）隔离开来。Docker 使用挂载点来重构 Docker 镜像中的文件系统，等等。