我有一个位于Git Stash Repository的项目。代码将部署在四个环境中（Dev，Test，Stage和Prod）。我们遵循敏捷方法。因此开发团队适用于发布活动和非发布（未来发布）活动。我必须根据这个要求创建分支。以下是我的计划。
三个稳定的分支：掌握，释放和发展。
master是默认分支。开发将由master创建。发布将从开发
创建功能分支 - ＆gt;它们将来自开发。每个开发人员都有一个功能分支，他们一旦完成就将代码合并到develop分支中。因此开发分支将发生开发环境部署。
如果需要更改测试环境，我们在这里有两种方法。一个是将开发分支与发布分支合并（测试环境部署将从发布分支发生）。我们无法实现这一点，因为开发分支可能同时具有发布和非发布更改。
另一种方法是将功能分支直接合并到发布分支中。这样每个开发人员的更改都可以合并到发布分支中。我不确定我是否可以实现这种方法。有人可以告诉我这种方式是否有效？是否有其他方法来处理这种情况。
分支：
主分支---＆gt;开发分支 - ＆gt;发布分支
开发分支---功能branch1 |功能branch2 | feature branch3
部署：
为 - >开发分支开发部署
发布分支 - ＆gt;测试部署
主分支 - ＆gt;阶段和产品部署
我无法将开发分支合并到发布分支。由于开发分支也有一些非发布变化。我只需要在发布分支上发布更改。功能分支可以直接合并到发布分支？这里最好的方法是什么？
答案 0 :(得分：10)
听起来对我来说，你非常接近选择Git Flow。实际上，如果我没有弄错的话，这就是你所描述的策略的基础。哪个好。
我听说你主要担心的是，你想要一个不释放＆＃34;开发＆＃34;分支，有点像＆＃34;只是尝试输出，可能无法编译＆＃34;环境/支。 Git流程确实有利于＆＃34;流动＆＃34;走向生产。即一旦将任何内容从其功能分支合并到 develop -branch中，它就会安排下一次（非紧急）发布。
Git flow关于如何处理这个问题的建议是不将任务/功能合并到 develop 中，直到它可能准备好进入下一个staging / prod - 或许有一些修复。在git flow中，你总是会与非快进（git merge --no-ff FEATURE_BRANCH_NAME）合并，这样如果你接近staging / prod-release，并且这个功能无法准备好，你可以反向合并（单个） merge-commit，从而将其从 develop 或 release -branch中删除。
我怀疑对此进行了较长时间的讨论，但只是为了推销，我看到了两种可能的方法来满足您的想法：
1）有2个开发分支：一个用于开发，开发分支，很快就可以在一些QA或其他任何内容后进行分段和产品发布。还有一个用于实验的东西，它将进入开发/测试环境（例如通过持续部署）。我们称之为 long-term-develop （这是一个糟糕而且太长的名字，所以要做一个更好的，或者你的团队会讨厌你:)）。
思想：
2）只有1个开发分支（按照你的建议）并从主人创建发布分支
这可能是迄今为止最简单的方法。每个开发人员需要花费更多的精力，但不容易出错。
程序将是：
-m选项合并到 release-sprint-42 ，将功能分支合并到 develop 中创建的合并提交，例如git cherry-pick -m 1 COMMIT_HASH。在这里，知道你选择哪一个家长非常重要（在我的例子中，父母1.开发应该阅读并理解http://git-scm.com/docs/git-cherry-pick）。思想：
总结
哪个是您的最佳选择，取决于您的发展方式。如果您有2首曲目，例如＆＃34;每日支持 - ＆＃34;和＃34;我的重要功能计划于今年12月发布＆＃34;，您可以选择2个分支机构。如果长期发展不是1，而是几件事情和持续进行的事情（即如果你通常有很多任务，跨越多个冲刺/周期），我会选择2。
理想情况下，我会默认推荐一种策略，其中的东西被分解成足够小的部分并且冲刺足够大，通常可以在1个冲刺中结束（即合并和部署！）任务/功能。但根据我所知的经验，这种一厢情愿的想法很少能够实施：）
最后一件事：我真的非常真的鼓励你没有1个发布分支（永久），而是为每个sprint / cycle创建一个新的发布分支，比如发布-sprint-42 ， release-sprint-43 ，等。 （无论你是基于开发分支在理想的git流程中还是在第二个场景中关闭master-branch，我建议）。根据我的经验，永久性的发布分支会导致缺失内容，合并问题和其他不良内容。除此之外， master 和 develop 应该是永久分支。
期待这次讨论：）