我在用作中央存储库的服务器上有一个裸露的git存储库。我已经安装了后收到钩，这样，当提交被推到这个仓库，在提交的更改使用以下命令部署到工作目录在同一台服务器上：执行git针对裸存储库提交的合法性
git --git-dir=path-to-repository --work-tree=path-to-working-directory checkout -f
我意识到，通过设置GIT_DIR和GIT_WORK_TREE环境变量在post-receive hook中，我也可以从命令行发出任意的Git命令。我并不是建议修改文件并从这个工作目录提交更改是一种很好的开发实践，特别是如果这是我的生产环境，但我是否从Git的角度来做任何事情非法？
......但我从Git的角度来做任何违法的事情吗？
不是。然而，重要的是要认识到这个稍微奇怪的状态的一些事情。
Git只有一个存储库，--git-dir告诉它在哪里找到这个存储库。
Git有只有一个工作树，和--work-tree告诉它在哪里可以找到一个工作树（和覆盖core.bare设置）。
Git只有一个HEAD（但看脚注1），而--git-dir告诉它在哪里可以找到那个HEAD文件。
Git只有一个索引，和... --git-dir告诉它在哪里可以找到一个索引，如果没有被环境变量设置覆盖。
这一趟的人了，使用主要是当post-receive脚本部署一些特殊的分支，这些最后一位。
如果您只将一个分支部署到一个工作树，那么这个索引不是问题。如果您开始将两个或更多分支部署到两个工作树，则一个索引成为问题。
同样，单个HEAD文件通常不是问题，尤其是当您以常规方式创建裸仓库时仅部署分支master，其中master作为其当前分支。 （一个裸存储库仍然有一个当前分支，这是HEAD文件中的一个。）当人们克隆裸仓库时，他们的克隆默认检查裸存储库中当前哪个分支是最新的 - 所以如果你开始部署几个不同的分支，人们可以从其存储库QA或test或develop或其他什么，而不是master开始的克隆感到惊讶。
（HEAD这个事情只是要求人们意识到他们的默认克隆分支可能会让他们感到惊讶，并且他们应该检查开发分支，如果这是他们想要的，那是单个索引文件造成真正的麻烦，所以请参阅脚注1。）
如果使用git worktree add，在Git的2.5及更高版本，这不再是真实的。额外的工作树当然提供他们自己的工作树，但也提供他们自己的单独HEAD，也是他们自己的索引。
可以提供使用环境变量GIT_INDEX_FILE，它总是覆盖Git的正常计算自己的指数。这也提供了一种方法来执行多个分支部署：让一个分支使用默认索引，并为其余索引文件（每个分配一个）。
对于push.denyCurrentBranch，使用多个工作区和新的updateInstead模式可能是自动化部署的更好方法，但我没有真正测试过。
最近的Git版本引入了一个“分割索引”，其中非常大的索引文件被“分割”为不会变化很大的部分，以及为了做出努力而做的部分Git更快。该指数分裂略魔术（虽然明显的确定性和可预测到底），并且知道如何处理备用索引文件，这样你就不会真的需要知道这事，但它使“一个索引文件”要求一有点怀疑。在任何情况下，增加从git worktree add worktrees仍然获得自己的索引文件（或索引对），因为这是必要的。