敏捷项目的Git分支策略

Question

我有一个位于Git Stash存储库中的项目。该代码将部署在四个环境(开发，测试，阶段和生产)中。我们遵循敏捷方法论。因此，开发团队既可以进行发布事件，也可以进行非发布(将来发布)事件。我必须根据此要求创建分支。下面是我的计划。

三个稳定的分支:掌握，发布和发展。

master是默认分支。发展将由主人创造。发布将通过开发创建

功能分支->它们将通过开发创建。每个开发人员都有一个功能分支，一旦完成，他们就将代码 merge 到开发分支中。因此开发环境的部署将发生在开发部门。

如果需要进行更改以进入测试环境，我们这里有两种方法。一种是将开发分支与发布分支 merge (测试环境部署将从发布分支进行)。我们无法实现此功能，因为developer分支可能同时具有发行版更改和非发行版更改。

另一种方法是将功能分支直接 merge 到发行分支中。这样每个开发人员所做的更改都可以 merge 到发行分支中。我不确定是否可以实现此方法。有人可以告诉我这种方式是否行得通吗？有没有其他方法可以处理这种情况。

分枝:

主分支->开发分支->发布分支

开发分支--- Feature Branch1 |功能branch2 |功能分支3

部署:

为->开发部署开发分支

发布分支->测试部署

->阶段和产品部署的master分支

我不能将开发分支 merge 到发行分支。由于develop分支也有一些非发布更改。我只需要在发布分支上进行发布更改。功能分支可以直接 merge 到发布分支中吗？最好的方法是什么？

Answer 1

在我看来，您非常接近选择Git Flow。实际上，如果您没记错的话，您所描述的已经是该策略的基础。太好了

我听说您的主要担心是，您想要一个非发布的“开发”分支，有点像“只是尝试，可能无法编译”的环境/分支。 Git流确实有利于生产的“流”。 IE。一旦将所有功能从其功能分支 merge 到开发分支中，就计划将其用于下一个(非紧急)发行版。

Git flow关于如何处理此问题的建议是，不要将任务/功能 merge 到开发中，直到它准备好进入可能具有一些修复程序的下一个阶段/产品发布为止。在git flow中，您将始终与非快进(git merge --no-ff FEATURE_BRANCH_NAME) merge ，这样，如果您即将接近暂存/产品发布，并且此功能无法使用，则可以将(单个)merge-commit反向 merge ，因此将其从显影或释放分支中移除。

我怀疑会对此进行更长时间的讨论，但只是为了说明一下，我看到两种可能的方式来满足您的想法:

1)有2个开发分支:一个用于开发，develop分支，不久将被安排进行一些QA或任何形式的开发和产品发布。还有一个用于实验的东西，将用于开发/测试环境(例如，通过持续部署)。让我们将其称为长期开发(这是一个不好的名字，而且名字太长了，因此请改成更好的imo，否则您的团队会讨厌您:))。

想法:

开发分支通常应 merge 到长期开发分支中，以始终保持更新。

您可能需要2个开发环境进行测试，每个分支需要1个。

危险:从长期开发创建的分支(可能由于错误而 merge ) merge 到develop中，可能会将更多尚未就绪的东西拖到develop分支中。解决此问题的方法可能是:1)将功能分支作为非快进 merge 到长期开发中； 2)樱桃选择将此提交 merge 到开发中。但这很容易出错，而且很复杂，一次错误的 merge 可能会使整个开发分支搞砸，并为尚未准备好进行登台/生产的东西造成污染。

2)(仅建议一个)只有1个development分支，并从主创建分支

到目前为止，这可能是最简单的方法。每个开发人员都需要花费更多的精力，但是出错的可能性较小。

程序将是:

在sprint/开发周期的每个开始，release-manager都基于master创建下一个release-branch。例如。 release-sprint-42，创建后等于主分支。

开发人员从develop的基础创建功能分支。他们将功能分支 merge 起来，以便在准备好进行测试时进行开发，等等。就像您目前所建议的那样。

如果功能是“正确的”并且可以正常工作，则使用-m选项将通过将功能分支 merge 到development中而创建的 merge 提交被选中，例如release-sprint-42。 git cherry-pick -m 1 COMMIT_HASH。在这里，真正重要的是要知道您选择的是哪个父级(在我的示例中，父级1.开发人员应阅读并理解http://git-scm.com/docs/git-cherry-pick)。

想法:

危险可能是，由于缺少依赖项，develop分支中使用的功能可能无法在release-sprint-42分支中使用。谢谢上帝，这就是为什么我们要有暂存环境和内部截止日期:)

cherry-pick 并不是最容易的事情。但是，绝对是避免 merge 中将不需要的代码拖到错误分支中的最佳方法。

汇总

哪种才是最佳选择，取决于您的发展方式。如果您有2条轨道，例如“每日支持资料”和“计划在今年12月发布的我的重要功能”，则可能需要2条分支。如果长期发展不是1，而是几件事情和一件持续的事情(即，如果您通常有很多任务，并且跨越多个冲刺/周期)，那么我会选择方法2。

不过，理想情况下，理想情况下，我会默认推荐一种策略，即将东西分解成足够小的块并且sprint足够大，以便通常可以在1个sprint之内完成一项任务/功能(即 merge 并部署!)。但是根据我的经验，一厢情愿的想法很少可以实现:)

最后一件事:我真的会真的 真的鼓励您不要拥有1个发布分支(永久)，而是为每个sprint/周期创建一个新的发布分支，例如release-sprint-42，release-sprint-43，等等。 (无论是基于理想git flow的develop-branch还是基于第二种情况的master-branch，我都建议)。根据我的经验，经常拥有永久的发行分支会导致缺少内容， merge 问题和其他弊端。除此之外，掌握和发展应该是永恒的分支。

期待这个讨论:)