敏捷项目的Git分支策略

Question

我有一个位于Git Stash Repository的项目。代码将部署在四个环境中（Dev，Test，Stage和Prod）。我们遵循敏捷方法。因此开发团队适用于发布活动和非发布（未来发布）活动。我必须根据这个要求创建分支。以下是我的计划。

三个稳定的分支：掌握，释放和发展。

master是默认分支。开发将由master创建。发布将从开发

创建

功能分支 - ＆gt;它们将来自开发。每个开发人员都有一个功能分支，他们一旦完成就将代码合并到develop分支中。因此开发分支将发生开发环境部署。

如果需要更改测试环境，我们在这里有两种方法。一个是将开发分支与发布分支合并（测试环境部署将从发布分支发生）。我们无法实现这一点，因为开发分支可能同时具有发布和非发布更改。

另一种方法是将功能分支直接合并到发布分支中。这样每个开发人员的更改都可以合并到发布分支中。我不确定我是否可以实现这种方法。有人可以告诉我这种方式是否有效？是否有其他方法来处理这种情况。

分支：

主分支---＆gt;开发分支 - ＆gt;发布分支

开发分支---功能branch1 |功能branch2 | feature branch3

---

部署：

为 - >开发分支开发部署

发布分支 - ＆gt;测试部署

主分支 - ＆gt;阶段和产品部署

我无法将开发分支合并到发布分支。由于开发分支也有一些非发布变化。我只需要在发布分支上发布更改。功能分支可以直接合并到发布分支？这里最好的方法是什么？

Answer 1

听起来对我来说，你非常接近选择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 （这是一个糟糕而且太长的名字，所以要做一个更好的，或者你的团队会讨厌你:)）。

思想：

• develop 分支通常应合并到 long-term-develop 分支中，以便始终保持更新。
• 您可能需要2个开发环境进行测试，每个分支需要1个。
• 危险：从 long-term-develop 创建的分支（可能是错误地）合并到 develop 中可能会拖得更多东西进入 develop 分支。对此的解决方案可能是：1）将功能分支合并为非快速进入 long-term-develop 和2）cherry-pick将此提交合并到 develop 中。但这很容易出错并且有点复杂，而且1个错误的合并会搞砸整个 develop 分支，用未准备好进行分段/生产的东西来污染它。

2）只有1个开发分支（按照你的建议）并从主人创建发布分支

这可能是迄今为止最简单的方法。每个开发人员需要花费更多的精力，但不容易出错。

程序将是：

• 在sprint / development-cycle的每个开始时，release-manager都会根据 master 创建下一个发布分支。例如。 release-sprint-42 ，创建时等于 master 分支。
• 开发人员使用 develop 创建功能分支。一旦它准备好进行测试，它们就会将功能分支合并到 develop ，等等。就像你目前的建议一样。
• 如果功能是＆＃34;正确＆＃34;和工作，通过将-m选项合并到 release-sprint-42 ，将功能分支合并到 develop 中创建的合并提交，例如git cherry-pick -m 1 COMMIT_HASH。在这里，知道你选择哪一个家长非常重要（在我的例子中，父母1.开发应该阅读并理解http://git-scm.com/docs/git-cherry-pick）。

思想：

• 可能存在危险， develop 分支中的功能可能无法在 release-sprint-42 分支中运行，因为缺少依赖项。感谢上帝，这就是为什么我们有临时环境和内部截止日期:)）
• 采摘樱桃不是最容易做到的事情。但绝对是尝试避免将不需要的代码通过合并拖入错误分支的最佳方法。

总结

哪个是您的最佳选择，取决于您的发展方式。如果您有2首曲目，例如＆＃34;每日支持 - ＆＃34;和＃34;我的重要功能计划于今年12月发布＆＃34;，您可以选择2个分支机构。如果长期发展不是1，而是几件事情和持续进行的事情（即如果你通常有很多任务，跨越多个冲刺/周期），我会选择2。

理想情况下，我会默认推荐一种策略，其中的东西被分解成足够小的部分并且冲刺足够大，通常可以在1个冲刺中结束（即合并和部署！）任务/功能。但根据我所知的经验，这种一厢情愿的想法很少能够实施：）

最后一件事：我真的非常真的鼓励你没有1个发布分支（永久），而是为每个sprint / cycle创建一个新的发布分支，比如发布-sprint-42 ， release-sprint-43 ，等。 （无论你是基于开发分支在理想的git流程中还是在第二个场景中关闭master-branch，我建议）。根据我的经验，永久性的发布分支会导致缺失内容，合并问题和其他不良内容。除此之外， master 和 develop 应该是永久分支。

期待这次讨论：）