要发布我的集中式 web 应用程序，我可以让一个虚拟主机指向某个目录，然后在我想要发布时执行“git pull”，更新文件。但是 Rails 有一个不同的部署机制：它将文件复制到一个子目录，然后将一个符号链接（'current'）指向那个新的子目录。
我知道进行类似 Rails 的部署可能更容易接受，因为发布是在某个目录中构建的，然后符号链接指向该目录，所以这要快得多，而且用户不太可能遇到奇怪的问题，同时正在发布。
Rails 方法还有其他优点吗？或者，“git pull”方法实际上是否被更广泛地接受？
我将用“Capistrano 方法”替换您问题中的“Rails 方法”。使用 Capistrano 有很多优点。您可以通过 SSH 从任何机器进行部署。如果发现错误，您可以cap:rollback立即撤消部署。您可以在部署发生之前在生产数据库上运行挂起的迁移。如果您有不同角色的不同机器，您可以立即部署到多台机器。安装后，请cap -T查看所有选项。
您正在描述 Capistrano 的行为，这在 Rails 项目中很常见，但不是 Rails 本身的一部分。Capistrano 的一种选择是使用 git 拉取远程服务器，这大大加快了部署速度，而不是推送 tar 包。
使用 cap 的一个主要优点是您可以定义在部署后执行任务的钩子，例如 sym 链接到共享资源和生成数据库配置文件。将各种环境的部署详细信息放在一个地方也很方便，而不是登录到每台服务器并手动执行更新。
首先让我澄清一下 capistrano 和 SCM（例如 git）不是相互排斥的选项。即使您使用 capistrano（或其他 ruby 部署系统之一）进行部署，您仍然应该使用某种 SCM 。
话虽如此，我会提倡使用某种 SCM 系统，如 git 或 mercurial 进行部署，而不是只在你必须部署在 Linux 以外的任何东西上时使用上限。我遇到了。我们需要部署到 Linux 和 Windows，因此 capistrano 不是一个好的选择，新版本（> 3）将不支持 windows，每个官方开发人员（它在 google 组上）。但这是使用 capistrano 与使用 git 或 hg 或 svn 手动操作相比的唯一缺点，我现在可以考虑。基本上所有 capistrano 和此类系统都可以通过让您在一个/两个命令行而不是 10 个命令行中部署应用程序来减轻您的负担。如果您必须在多个系统/机器上部署，它特别有用。
如果需要，您还可以推出自己的脚本/解决方案，这是我们为支持 windows 必须做的。
Capistrano 也可以配置为使用基于 git 的部署——你仍然可以享受“cap deploy:rollback”的乐趣，但没有所有额外的发布目录（和相应的磁盘流失）：