（dis）使用'drush rsync'与'git'进行dev->生产的优势？

我在git的控制下建立了一个Drupal网站进行开发工作。

它以一个原始的裸GIT仓库为主体，并且随着我在各种项目工作git克隆中所做的更改，然后又将其推送回主体，更新后的挂钩立即将所做的更改推送到单个实时Staging网站（http：/ /staging.loc。）。没什么特别的，按预期工作。

我还对站点“ @STAGING”进行了别名处理。偶尔，我想将我的更改从暂存站点升级到生产服务器。

我想到了两种相对简单的方法：

（1）在登台站点稳定的某个时间点，将生产站点创建为从主存储库的git checkout，

（2）从临时站点到生产站点使用drush rsync+ drush sql-sync。

两者都可以工作。除了（2）本质上似乎更以Drupal为中心/意识到这一事实之外-繁琐毕竟是一组Drupal特定的工具-两种方法的相对优点是什么？

我应该考虑（1）而不是（2）的任何特殊原因吗？

无论哪种情况，“一切”都至少在一个版本控制下。

我已经使用了两种技术。两者都可用于确保您在@stage上测试的相同文件最终在@live上。rsync的优点是您不会在生产服务器上得到多余的文件（例如“ .git”和相关文件）。我倾向于rsync到vps，并在我拥有的盒子（例如Intranet站点）上使用git。

使用drush rsync的问题是，如果有多个人将更改推送到服务器。

您的示例仅显示一个人推动更改。

如果您让开发人员A推动更改，然后让开发人员B推动更改，则您希望git消除冲突，或者让开发人员B消除冲突。

我实际上都使用。svn / git和rsync有两个不同的用途。SVN / GIT中是源控制，rsync并且sql-sync是用于高效地同步分期和刺。如果您想深入研究代码质量的疯狂/方法，那么drush rsync @staging @prod在简单性方面很难被击败，并且在大多数continuous Integration环境中都非常容易集成。

我个人使用Git进行版本控制，部署和同步各种服务器代码库，然后使用rsync来移动/同步用户文件（通过将某些路径添加到.gitignore文件来忽略）。