我们正在概述和准备 Git 集成，我们正在实施与以下链接类似的设计。
http://nvie.com/posts/a-successful-git-branching-model/
我们遇到的问题是当您提交并推送到“开发”分支或持续集成分支时，由于我们有多个团队在不同的分支上工作，您必然会遇到合并冲突，因为您永远不会从“开发”中退出'在推动之前。对于团队推动尝试解决他们不太了解的事情来说，这似乎不是最佳实践。
我们的一个想法是在“开发”分支上提出拉取请求，并拥有一个致力于解决这些问题的团队。
他们是我们缺少的任何选择吗？
特性分支背后的想法是它们应该只包含一个小的、原子的变化。由于其本质，这种更改理论上不应导致合并冲突。
如果某个功能引入了合并冲突，我会更倾向于检查您认为是“一个功能”的内容。
我体验过这种介绍的方式是，一项功能与一项特定任务相关，该任务（就时间而言）应该持续不超过一两天。
鉴于时间跨度很短，合并冲突不太可能在周期中出现，但如果发生合并冲突，例如当您有多个团队在代码库的同一区域工作时，需要一定程度的沟通以确保以正确的方式解决冲突。
您可以应用不同的模型来帮助您管理冲突解决方案。我们使用水平切片模型，如果多个团队需要在代码库的特定区域进行更改，则将其分配给项目包含整个给定模块的团队。您的公司可能对垂直切片模型更感兴趣，在这种情况下，您不太可能遇到跨团队的合并冲突。
再多的工具都无法击败解决冲突的对话。如果您知道您的更改会影响其他人正在处理的文件，那么最好遵循的模型是对话。
在某些情况下，这并不理想，业务可能对谁的更改何时发布有其他想法，但只要每个开发人员保持他们的功能分支与开发保持同步，那么冲突的可能性就会大大降低。