基于环境的分支战略和GIT的良好实践

Question

我一直在看基于功能的分支策略，我看到master和dev长时间运行。

我正在寻找一个你有dev - > UAT - > master的场景。 并非所有dev中的提交最终都会推送到UAT分支，并且UAT中的所有提交都不会进入UAT（即如果UAT失败则不会进入生产阶段）。 有可能或良好做法吗？

另一个问题，如果dev分支中的所有开发都是99％完成修复的提交吗？ （即在合并到开发之前在远程/本地分支中进行了所有测试）我的问题超出了我的目的，因为我们让开发人员提交1-2个内核修复来测试他们的代码。 这使得git历史非常混乱。

Answer 1

我的问题超出了我的目的，因为我们让开发人员提交1-2个内核修复程序来测试他们的代码。

这通常在特征分支上完成，然后将其合并为no-ff（无快进），以便将其内部历史记录压缩为一个提交一个dev。

Dev可以是一个集成分支，您可以在其中合并这些功能分支：如果其中一个功能不能使其生成，您只需还原代表该功能的合并提交 。 git flow有点像那样。