当使用包含所有源资产的 git 存储库和需要在运行之前运行的gulp/grunt构建脚本或composer install时，将其部署到生产服务器的最佳方法是什么？以下是我想出的一些解决方案：
-
保留生产阶段的本地副本（运行构建脚本和编辑器安装，然后通过 （s）ftp 部署到服务器）。这似乎不切实际，并且至少会向部署过程添加一个额外步骤。
-
创建一个分发分支，跟踪那里的编译/串联/缩小文件。这似乎不直观，并且与第一个选项一样，为部署过程增加了一个额外的步骤。
-
使用 capistrano 或第三方部署工具（将通过 ssh 连接到生产服务器）、克隆存储库、运行构建脚本并创建指向新安装版本的符号链接。这似乎是"最整洁"的解决方案，尽管它需要对服务器的完全访问权限，并且可能会有一些安全隐患。
我一直遇到这个问题，到目前为止，我已经采用了第一个选项（根据我的经验，这更像是一种手动解决方法）
我见过的一种工作方法是将本地构建脚本与简单的 git 部署相结合，并使用两个存储库：例如 src 和 www。
-
您的 src 存储库包含源代码和构建脚本、测试等。
-
构建在本地运行（作曲家，grunt，sass，js-min等），并将"静态"结果输出到www存储库中的www/htdocs文件夹。
-
www 存储库由生成提交并推送到部署远程。
-
部署远程位于生产 www 服务器上，带有一个接收后钩子，它将头部（从/var/git/yourdomain 中的裸存储库）签出到 Web 服务器（例如在/var/www/yourdomain）中，这是一个 git 工作目录。
它基本上很简单，几乎没有专有技术（除了grunt，作曲家和git），但当然细节需要一段时间才能正确。
我发现构建分支是一场噩梦，部分原因是 git 在跟踪文件方面的顽强态度以及必须避免一些合并。例如，这使得进行构建清理变得非常困难。你至少必须有一个单独的www文件夹，你可以构建到一个基本上复制任何未编译的后端脚本（如PHP）中。版本控制和分支开发与版本有时会不一致。拥有两个存储库可以完全分离这一点，并允许您将部署分支部署到不同的网站，例如（暂存、生产）。
当然，git 部署方法意味着您确实需要对主机的"完全"访问权限才能安装 git、钩子并拥有 ssh 访问权限。但是大多数网络主机都提供ssh访问权限？
我发现 git 部署非常可靠且无故障。