作者回复: 我理解你说的develop应该就是每个开发人员在开发需求时，从master分支上来出来的个人开发分支吧？这个实际上就是feature branch模式。这种模式其实是有一些问题的，比如你的代码是没法持续push/merge的，只能等开发完成后才merge全部代码，没有办法做到真正的持续集成，同时对重构也不友好，因为merge的频率太低了，重构会导致大量的冲突。 而且如你所说的，各个分支切来切去，还要想着向各个环境去merge代码，开发人员除了开发需求外，脑子里还得想着各种跟开发需求无关的东西，大大提高了认知负载。 更理想的分支策略当然是主干开发，但这也是有一定门槛的，国内真正能实施主干开发的项目也并不多，一方面对于人员能力要求比较高，另一方面对需求管理的要求也比较高，尽量不要让需求临时中止开发。但这些都属于内在认知负载，一旦掌握就一劳永逸。而不像内在认知负载那样，需要时刻想着这个想着那个。主干开发还可以解决多分支切换的问题，因为你的代码始终是可以merge的，你可以把手头的代码merge完之后继续在主干上修复bug。 所以我建议你根据自己项目的实际情况进行改善，比如是否可以将比较稳定的需求（或者一个团队内部）建立一个公共分支，某种程度上可以作为你们的主干，可以解决合并冲突和不敢重构的问题。 分支策略是个讨论不完的话题，我甚至觉得光这个就能写一个专栏了……