两个目标环境的Git分支模型

我对通过git进行版本控制的php项目还不熟悉。开发工作分配给两到四名开发人员，他们在不同的分支中处理各自的特性。有两个永恒的分支，

master

，这是一个可以部署到生产环境的版本，

develope

，其中当前的开发集成并部署到测试环境中

当特性准备好进行测试时，它将合并到部署到测试服务器的

develope

分支中，客户端将测试特性。此测试过程通常需要几天，有时需要几周，直到某个功能获得批准。当一个特性被批准后，它将被立即集成到生产系统中

由于这个测试和反馈周期非常缓慢，所以测试和生产阶段的发布版本截然不同。由于无法将

develope

合并到

master

中，因此很难将功能发布到生产环境中-这将在

master

中引入未经客户批准的提交/功能。因此，每个功能分支都必须合并到

develope

中，并在明确批准后合并到

master

中

缓慢的测试过程还有一个缺点，一些特性可能会对同一文件进行更改，然后将这些更改集成在一起，以便在测试服务器上进行测试。这使得有必要合并这两个功能以将其部署到测试服务器，然后在其中一个功能获得批准并应部署到生产环境中时将其拆分

你认为什么是解决这种情况的好方法？我们是否应该批处理功能并使用固定的发布周期，例如每周一次

---

我们如何开发和发布临时特性，哪种分支模型更合适？或者你认为将功能分支合并到

develope

，然后再合并到

master

-永远不要将

develope

合并到

master

？

你应该检查一下，我会给你2012年有人给我的建议：如果有疑问，请接受。在您的特殊情况下，发布分支也解决了“将功能合并到主功能”的问题。我认为当前的方法是受GitFlow启发的，我还认为它增加了很多混乱和规则：哪个分支合并到另一个分支，何时使用它等等。我认为所有的开发人员（包括我自己）对git没有那么深入，因此，没有定义的过程。也许这是比分支方法更大的问题。如果发布分支用于在最后一分钟调整产品推出，那么如果它专门针对

master

进行了优化，它如何合并回

develope

？