如何实现DEMO发布
我和我的团队正在使用 GitFlow 对我们的代码进行版本控制，但现在我们需要为 DEMO 创建第三个分支，以便能够
- 从 DEMO 中的 DEVELOP 发布进行测试，然后在所有测试通过后从 DEMO 发布到 MASTER
- 合并来自 DEMO 的修复DEVELOP
- 将修补程序从 MASTER 合并到 DEMO 和 DEVELOP 同时，
这里是版本控制流程的草稿（我希望它有帮助）：
我找不到 GitFlow 的解决方案，有什么建议吗？我们应该选择其他工具吗？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这个问题听起来像是部署过程的结果，而不是 Git 合并策略的结果。
GitFlow 中没有
demo分支的概念，尽管听起来您本质上是在尝试使用release分支。值得注意的是，GitFlow 本身没有任何内容可以精确控制您部署任何分支的方式，并且是否使用 GitFlow 的选择应该独立于您的服务器架构。听起来您正在寻找的是将
release分支部署到独立的测试服务器，然后对其进行测试。一旦测试通过，您就可以将相同的提交（在release分支上）部署到生产服务器。这样您就不必担心特定于测试的单独分支。请注意，master本身不应部署到生产环境中；它仅被视为对代码的最后一个已知稳定版本的“引用”。您应该在部署（并标记提交）后立即合并回master，以防将来需要恢复到目标版本。下面显示的标准 Git 流程对此进行了说明：
为了更进一步，还有一个 DevOps 测试概念 shifting-left，其中
develop分支本身是测试的对象，并且被认为本身是可发布的。这进一步简化了流程，选择这种方法有利有弊。评估后可能值得考虑。This problem sounds like it has arisen as a result of deployment processes, not Git merging strategy.
There is no concept of a
demobranch in GitFlow, though it sounds like you're essentially trying to make use of areleasebranch. It's worth noting that there is nothing in GitFlow itself to regulate exactly how you deploy any of your branches, and the choice of whether or not to use GitFlow should be made independent of your server architecture.What it sounds like you're looking for is to deploy out a
releasebranch to an independent testing server, then test against that. Once the tests pass, you can deploy the same commit (on thereleasebranch) out to the production server. This way you don't need to worry about a separate branch specific to testing. Note thatmasteritself should not be deployed to production; it is merely considered a 'reference' to the last known stable version of the code. You should be merging back tomasterstraight after a deployment (and tagging the commit) in case you need to revert back to the target version in the future.This is illustrated in the standard Git Flow shown below:
To take this a step further, there is also a DevOps testing concept of shifting-left, where the
developbranch itself is what is tested against, and considered to be shippable in itself. This simplifies the process even further, and there are pros and cons to choosing such an approach. It may be worth considering after evaluation.