我会给出与Adarsh Shah相同的建议，因为在大多数情况下，2个分支(MAIN，RELEASE)就足够了，并且使用feature branches用于你不想立即提交到MAIN的东西，因为它需要一段时间才能完全准备好测试 . 通过RELEASE，我指的是每个实际版本的分支 .

请记住，从理论上讲，MAIN应该随时处于释放就绪状态 . 这意味着使用特征分支也可以进行大量的小改动，只要该功能不被认为是准备好的，就不会将东西合并到MAIN中 . 现在，您应该尝试这一点，看看哪种方式最适合您的环境 . 如果您发现将MAIN保持在发布就绪状态太难了，请务必创建一个单独的DEV分支来提交日常工作 . 然而，根据我的经验，通过一些良好的指导，自动和手动测试，您可以快速进入MAIN可以被认为非常稳定的流程 . 我曾经在我们有一个非常不稳定的DEV分支和一个稳定的MAIN分支的环境中工作，以及我们没有DEV分支的环境 . 有时需要DEV分支，有时它会使它们保持同步，因为DEV和MAIN都相当稳定，基本上只是彼此的副本 .

现在，何时应该创建发布分支 . 这取决于您正在进行的开发类型 . 对于小型桌面项目或具有相当稳定的发布周期的网站(例如，每个sprint发布一个版本)，我发现在sprint结束时创建一个发布分支最容易，之后只能将其推送到 生产环境 sprint .

S1 - - S2 - - S3 - - S4 // Each sprint

\ R1 - \ R2 - \ R3 // Release branch created at the end of a sprint

\ P1 - \ P2 // Pushed to production at the start of the next sprint

因此，在S1结束时，我从MAIN创建了发布分支R1，但它尚未推向 生产环境 阶段 . 在S2期间，两个新功能都在MAIN上实现，并且关键错误在R1上得到修复 . 如果R1上的修复程序被批准，它也会被合并回MAIN，如果需要的话 . 在S2结束时，创建一个新的R2，并将R1推入 生产环境 环境 . 我发现这种方法很有效 . 你基本上有一个完整的sprint来解决发布分支中的最后一个问题 .

当然，如果 生产环境 中出现严重的关键错误，则此错误优先于其他所有错误 . 然后可以创建正在 生产环境 的现有R分支的RXa，RXb，...分支，实现热修复并将该热修复推送到 生产环境 中 . 然后你可以考虑是否需要它将热修复中的更改合并到MAIN分支中 . 不要在MAIN分支上创建一个热修复并将其合并，但是你会发现它很快变得太复杂，因为在MAIN上很多周围的代码可能已经改变了 .