使用'git pull'与'git checkout -f'进行网站部署的区别

Question

我发现了两种常见的方法来使用一个裸的远程仓库自动部署网站更新。

第一种方法要求将仓库克隆到Web服务器的文档根目录中，然后在post-update钩子中使用git pull。

cd /srv/www/siteA/ || exit
unset GIT_DIR
git pull hub master

第二种方法是向裸仓库添加一个“分离的工作树”。post-receive钩子使用git checkout -f将仓库的HEAD复制到工作目录中，该目录是Web服务器文档根目录，即：

GIT_WORK_TREE=/srv/www/siteA/ git checkout -f

第一种方法的优点在于，可以将网站工作目录中进行的更改提交并推送回裸仓库（但不应在实际服务器上更新文件）。第二种方法的优点在于git目录不在文档根目录内，但这很容易通过使用htaccess解决。

在最佳实践方面，是否有一种方法比另一种方法更为客观？我还缺少哪些优点和缺点？

- Michelle

Answer 1

在发布管理（即部署）方面，最好拥有一个与发布机制无关的目标环境。

换句话说，第二种解决方案（checkout -f）将修改一个纯网站目录结构，没有任何其他不应包含其中的子目录（如.git文件夹）。

例如，我在“使用 Git 将我的 Node.js 应用部署到生产服务器”中使用它。

这最小化了任何副作用，并允许生产环境仅使用必要的内容来运行，没有干扰。

- VonC

---

我不清楚如果没有一个“目标环境与发布机制独立”的风险/缺点是什么。我所能想到的就是你提到的 - .git文件夹，可以通过使用必要的.htaccess规则轻松缓解。我错过了什么吗？非常感谢任何建议。 - Michelle

@Michelle，就发布管理而言，您尝试对生产平台上的内容进行严格控制：它应该只包括运行应用程序所需的内容，不包括其他任何东西，也不包括额外的工具（如git）。话虽如此，这只是一种“通常的最佳实践”，而不是绝对规则，在您的情况下，您完全可以直接在生产平台上保留git存储库。 - VonC

@VonC 如果一个网站的图片/ pdf 通过管理面板添加/更改，那么 hook checkout 在下一次运行时会覆盖它们。 对于一个大型（~10GB文件）的网站，每次进行（甚至是小的）推送时检查整个站点是否会成为问题。 - Hayden Thring

@VonC，我刚查了一下它的文档，还是不太清楚，我应该用restore而不是checkout吗？如果是这样的话，你的意思是它会保留那些未更改的现有文件吗？ - Hayden Thring

@HaydenThring 是的，而且是的。 - VonC