管理长时间运行的功能分支（可能需要多个基准操作）的正确方法？

Question

我知道您不应该在更改基准后将更改推送到远程服务器，并且有点知道原因。但是，请设想以下情形：

• 制作功能分支
• 干活
• 变基
• 推送和文件提取请求
• 一切都好吧？错误！集成管理器拒绝您的功能并添加评论
• 修复您的功能
• 与此同时，master继续前进，所以您再次调整了基础...
• 糟糕！现在您正在重新部署已经推入的分支！

处理此问题的正确方法是什么？

Answer 1

  

“ 您不应该将更改推送到远程服务器上，直到重新设置”

我完全不同意这个说法；您所描述的内容均不保证重新定基。

您所描述的问题听起来像您仅仅在您的遥控器上有一个master分支，而您正在分支的功能也由此分支了。这与 Git Flow 不符。

不用担心-长时间运行的功能分支-这是很正常的事情，并且可以很好地将这样的分支重复推到origin。由于在Git中进行了备份（您提到过），因此甚至建议您这样做。

您将要遵循典型的Git Flow：

1. 您有一个master分支连接到您的生产环境，
2. 您从develop分支中分支了master
   （并将其连接到开发和测试环境）。
3. 您从{strong> feature （而不是develop）
分支您的每个master
4. 无论功能是否完整，您都可以随时提交origin/feature/your-branch，
5. 该功能完成后，您将通过请求请求合并到develop。
   这是唯一应该发生冲突的地方！
   • 如果存在冲突，请通过pull将develop分支放入本地要素分支，将其修复在您的 local 分支上。您可能需要先stash进行更改。然后，您可以push的本地分支返回到origin －功能分支尚未合并。
   • 解决冲突后，分支合并到develop中。
然后
6. develop部署到您的开发环境中（最好是通过持续集成工具（例如Jenkins或TeamCity）自动进行）。这样，开发环境始终具有所有最新功能。

1. 对功能进行全面测试后，您将创建功能的发布版本，并将该版本发布到master（已部署到生产环境）。此时，在分支上添加tag也很有益，这样您可以确切知道当前正在生产的版本。

这样，您将永远不会遇到在合并之前将代码推送到origin/feature/your-branch会对其他开发人员或环境造成任何类型的问题的情况。这也意味着，将功能合并到develop中之后，您的生产环境仍将不包含该功能，因此您不必担心。您可以在功能投放生产服务器之前自由测试该功能。