使用 git 进行部署与发送 .tar.gz 相比有什么明显的优势吗？

Question

此问题旨在区分两种部署方法之间的事实差异，而不是主观的。查看最后的列表以了解具体概念。

我目前正在寻找从构建应用程序的任何位置部署应用程序的选项。我一直在阅读并熟悉 git 有时如何用于部署。我还看到了如何简单地创建所需文件的 tar.gz，然后将其发送到服务器。

我对此想得越多，我就越觉得简单地编写脚本创建和发送存档比依赖 git 进行部署更简单并且“更静态”。

到目前为止，让我喜欢简单存档的主要因素是：

• 目的地不必安装 git 或任何其他工具
• 我不必为目的地上的依赖项检查设置任何特殊键
• 使用 git 时，部署的仓库总是比实际部署的代码大
• 我将少一个 git 存储库来保持一致
• 在我的具体情况下，我还具有在 git 存储库之外构建或检索的依赖项（composer、bower、grunt）
• 我可以选择要部署的文件子集，而不是整个分支/标签
• 准备好的包是我网站的一个完整的发行版，几乎就像一个二进制文件

进一步阅读：

• http://gitolite.com/deploy.html#why-git-is-not-a-deployment-tool

Answer 1

这两种方法之间的主要区别（除了在生产服务器上安装 Git）是必须通过网络传输的文件数量：传输的文件越少，整个过程就越不容易出错。

这就是为什么我更喜欢使用git archive 来生成所需的 tar 文件（包含命名树的树结构的指定格式的存档）。

这样，我只需要传输一个文件，作为常规存档，而另一端不需要 Git。

Answer 2

我有两种不同的方法来做这件事。一种是实际将 git repo 克隆到服务器上，然后从服务器上的命令行拉取。第二种是使用像http://dploy.io/ 这样的部署工具，它(s)ftp 将文件从repo 发送到服务器。

在这两种情况下，我都会从存储库中删除通过（composer、bower、grunt）安装的任何内容，并在需要时从服务器上的命令行手动执行此操作。我对这两种方法的工作流程都很满意，并使用一种更适合部署到的服务器和需要进行未来部署的团队的方法。