敏捷项目的Git分支策略

Question

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

三个稳定的分支:掌握,释放和发展.

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

功能分支 - >它们将从开发中创建.每个开发人员都有一个功能分支,他们一旦完成就将代码合并到develop分支中.因此开发分支将发生开发环境部署.

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

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

分枝:

master branch ---> develop branch - > release branch

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

---

部署:

为 - > dev部署开发分支

发布分支 - >测试部署

主分支 - >阶段和prod部署

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

Answer 1

听起来对我来说,你非常接近选择Git Flow.实际上,如果我没有弄错的话,你已经描述过,这已经是你策略的基础了.哪个好.

我听说你主要担心的是,你想要一个非发布的"开发"分支,有点像"只是尝试输出,可能无法编译"环境/分支.Git流确实有利于生产的"流动".即,一旦将任何东西从其功能分支合并到develop -branch中,它几乎计划用于下一个(非紧急)版本.

Git flow关于如何处理这个问题的建议是不将任务/特性合并到开发中,直到它可能已准备好进入下一个staging/prod-release并且可能有一些修复.在git flow中,你总是会与非快速前进(git merge --no-ff FEATURE_BRANCH_NAME)合并,这样如果你接近staging/prod-release,并且这个功能无法准备,你就可以反向合并(单个)merge-commit,从而将其从开发或发布中移除- 分支.

我怀疑对此有一个更长时间的讨论,但只是为了推销,我看到了两种可能的方法来满足你的想法:

1)有2个开发分支:一个用于开发,开发分支,很快就会在一些QA或其他任何问题后进行分期和产品发布.还有一个用于实验的东西,它将进入开发/测试环境(例如通过持续部署).让我们称之为长期发展(这是一个糟糕的,太长的名字,所以做一个更好的,或你的团队会恨你:)).

思考:

• 开发分支应该经常合并到长期开发分支,以便始终保持更新.
• 您可能需要2个开发环境进行测试,每个分支需要1个.
• 危险:从长期开发中创建的分支(可能是错误地)合并到开发中可能会将更多未准备好的东西拖入开发分支.解决方案可以是1)将特征分支合并为非快速的长期开发和2)樱桃选择合并此提交进行开发.但这很容易出错并且有点复杂,而且1个错误的合并会搞砸整个开发分支,用未准备好进行分段/生产的东西来污染它.

2)只有1个开发分支(按照你的建议)并从master创建发布分支

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

程序将是:

• 在sprint /开发周期的每个开始时,release-manager都会创建基于master的下一个release-branch .例如release-sprint-42,它在创建时等于master分支.
• 开发人员创建功能分支从基地发展.他们合并功能分支来发展,一旦它已经准备好进行测试,et.c. 就像你目前的建议.
• 如果功能"正确"并且正常工作,那么通过将选项转换为release-sprint-42,可以将通过将功能分支合并到开发中创建的合并提交进行挑选.这里非常重要的是要知道,你选择哪一个父母(在我的例子中是父母1.开发应该阅读并理解http://git-scm.com/docs/git-cherry-pick).-mgit cherry-pick -m 1 COMMIT_HASH

思考:

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

围捕

哪个是您的最佳选择,取决于您的发展方式.如果您有2首曲目,例如"每日支持 - 东西"和"我计划于今年12月发布的大功能",您可能会选择2个分支.如果长期发展不是1而是一些事情和持续的事情(即如果你通常有很多任务,跨越多个冲刺/周期),我会选择2.

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

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

期待这个讨论:)