我们使用前端代码，例如HTML、CSS、JS 等
我们在 Github 上有一个预览分支 (qa)，当推送到该分支时，它会自动将代码部署到预览网站，供我们的 QA 团队进行测试。
我们将代码编译/构建到 dist 目录中，并在预览网站上提供。当然，dist 目录通常会被忽略。
我们如何推送我们的开发分支并始终覆盖我们的预览分支？
我们希望忽略任何冲突并始终使用我们推送的新代码。预览分支中的代码永远不应该渗透到开发分支中。我们从不直接在预览分支中处理代码。
上下文
我们是一个小型但地理位置分散的团队，我们从事具有多个发布波次的大型前端项目。没有这样的生产，因为我们的工作是提供给管理与内部 CMS 系统等集成的其他团队。
master 分支代表最后一个版本。通常我们会按顺序工作，即处理 wave1 并发布到 master，处理 wave2 并发布到 master等等。然而，有时我们在处理 wave2 时需要对 wave1 应用修补程序。 wave1 中的修复将需要临时部署到 qa 进行测试。
我们创建功能分支并使用 Pull Requests 将它们 merge 到当前 wave 分支中。
目前我们使用此策略将当前 wave 部署到 qa:
git push origin wave2:qa
然而这通常会导致 dist 目录发生冲突，在这种情况下我们这样做:
git checkout qa(本地 checkoutqa分支)git pull(确保它是最新的)git checkout wave2(切换回wave分支)git merge -s ours qa( mergeqa分支，使用 ours 策略)git checkout qa(切换回qa)git merge wave2( mergewave2中)git push(推送部署)
现在我注意到这确实破坏了我们的提交历史，如果我们需要将旧 wave 部署到 qa 以进行修补程序测试，我们最终可以提交(并编写一些代码次)在我们的 wave1 分支中应该只在我们的 wave2 分支中。
我觉得这一切都有点不对劲，但我不确定最好的解决方案是什么。我想也许我们正在尝试使用我们的策略将方钉装入圆孔中。
我们应该改用 git push origin wave2:qa --force 吗？
或者我们应该为预览分支准备一个不同的 Remote ？
或者也许构建步骤应该在服务器上进行，以便 dist 目录不在 repo 中？
很高兴在我们当前的策略之外工作，因为无论如何我们都想转向更严格的 git flow 模型。
我们真正需要的是一种技术，使我们能够轻松地将我们的工作部署到预览站点，而不会遇到冲突问题或分支/发布的交叉污染。
最佳答案
How can we push our development branches and always overwrite our preview branch?
Should we be using git push origin wave2:qa --force instead?
git push -f ...
-f (--force) 用于强制推送。它将覆盖远程分支的当前内容。您只需验证您是否拥有这样做的权限。
关于git - 总是覆盖一个 git 部署分支，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/34400629/