敏捷项目的 Git 分支策略

Git branching strategy for Agile project

提问by Ela

I have a project that is located in Git Stash Repository. The code will be deployed in four environments(Dev, Test, Stage and Prod). We follow Agile methodology. So dev team works for both Release activities and Non Release( Future Release) activities. I have to create branches based on this requirement. Below is my plan.

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

Three stable branches: master, release and develop.

三个稳定的分支：master、release 和 develop。

master is the default branch. develop will be created from master. release will be created from develop

master 是默认分支。开发将从主人创建。版本将从开发创建

feature branches --> they will be created from develop. each developer has one feature branch and they merge the code into develop branch once done. so dev environment deployment will happen from develop branch.

功能分支 --> 它们将从开发中创建。每个开发人员都有一个功能分支，一旦完成，他们就会将代码合并到开发分支中。所以开发环境部署将从开发分支发生。

if changes need to go Test environment, we have two ways here. one is merge the develop branch with release branch( Test environment deployment will happen from release branch). We can not implement this since develop branch may have both release and non release changes.

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

another one way is merge the feature branches directly into release branch. so that each developers changes can be merged into release branch. I am not sure whether i can implement this method. Can someone please tell me if this way will work? is there any alternate way to handle this situation.

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

branching:

分枝：

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

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

develop branches --- feature branch1 | feature branch2 | feature branch3

开发分支---功能分支1 | 功能分支2 | 功能分支3

---

---

deployments:

部署：

develop branch for --> dev deployments

为 --> 开发部署开发分支

release branch for --> test deployments

发布分支 --> 测试部署

master branch for --> stage and prod deployments

用于 --> 阶段和生产部署的主分支

I can not merge develop branch into release branch. Since develop branch has some non- release changes as well. I need only release changes on release branch. can feature branches be merged into release branch directly? What is the best approach here?

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

回答by Frederik Struck-Sch?ning

it sounds to me like, you are very close to choosing Git Flow. Actually, if I'm not mistaken, this is already your base from the strategy, you describe. Which is great.

在我看来，您已经非常接近选择Git Flow 了。事实上，如果我没记错的话，这已经是你的策略基础了，你描述的。这很棒。

I'm hearing your main concern is, that you want a non-release "develop" branch, sort of like a "just trying stuff out, might not compile" environment/branch. Git flow indeed favours a "flow" towards production. I.e. once anything is merged from its feature-branch into the develop-branch, it's pretty much scheduled for next (non-emergency) release.

我听说您主要担心的是，您想要一个非发布的“开发”分支，有点像“只是尝试一下，可能无法编译”环境/分支。Git 流程确实有利于生产的“流程”。即一旦任何东西从它的特性分支合并到开发分支，它就几乎被安排在下一个（非紧急）版本中。

Git flow's suggestion on how to handle this, is to not merge a task/feature into develop, until it's probably ready enough to go into next staging/prod-release with maybe a few fixes. In git flow, you would always merge with non-fast forward (git merge --no-ff FEATURE_BRANCH_NAME) so that if you are getting near a staging/prod-release, and this feature cannot get ready, you would reverse-merge the (single) merge-commit, thus removing it from the developor release-branch.

Git flow 关于如何处理这个问题的建议是，不要将任务/功能合并到develop 中，直到它可能准备好进入下一个暂存/产品发布并进行一些修复。在 git flow 中，您将始终与非快进 ( git merge --no-ff FEATURE_BRANCH_NAME)合并，以便如果您接近暂存/生产发布，并且此功能无法准备好，您将反向合并（单个）合并提交，因此从开发或发布分支中删除它。

I suspect a longer discussion about this, but just to pitch, I see 2 possible ways to meet your ideas:

我怀疑对此进行更长时间的讨论，但只是为了推销，我看到了两种可能的方法来满足您的想法：

1) Have 2 develop-branches: one for development, developbranch, that will soon be sceduled for staging- and prod-release after some QA or whatever. And one for experimental stuff, that will go to a dev/test-environment (e.g. through continuous deployment). Let's call it long-term-develop(this is a bad and too long name imo, so make a better one, or your team will hate you :) ).

1) 有 2 个开发分支：一个用于开发，开发分支，在一些 QA 或其他之后很快将被安排用于暂存和产品发布。一个用于实验性的东西，将进入开发/测试环境（例如通过持续部署）。让我们称之为长期发展（imo，这是一个糟糕且过长的名称，因此请改名，否则您的团队会讨厌您:)）。

Thoughts:

想法：

• developbranch should often be merged into long-term-developbranch, to always keep it updated.
• You would probably need 2 develop-environments to test, 1 for each of the branches.
• Danger: branches created from long-term-developthat are (perhaps by mistake) merged into developcould drag more not-ready stuff into developbranch. Solution for this could be to 1) merge feature-branch as non-fastforward into long-term-developand 2) cherry-pick merge this commit into develop. But this is error-prone and kind of complicated, and 1 wrong merge could screw up entire developbranch, polluting it with stuff not ready for staging/production.

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

2) Have just 1 develop branch (as you suggest) and create release-branches from master

2）只有1个开发分支（如您所建议的）并从主创建发布分支

This is probably by far the easiest way. It takes a little more effort from each developer, but is less error prone.

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

Procedure would be:

程序是：

• At each beginning of a sprint/development-cycle, release-manager creates the next release-branch based off master. E.g. release-sprint-42which, when created, equals masterbranch.
• Developers create feature-branches with base from develop. They merge feature-branch to developonce it's ready for testing, et.c. Like you currently suggest.
• If feature is "correct" and working, the merge-commit that was created from merging the feature-branch into developis cherry-picked with the -moption into release-sprint-42, e.g. git cherry-pick -m 1 COMMIT_HASH. Here it's really important to know, which parent you are picking (in my example parent 1. Develops should read and understand http://git-scm.com/docs/git-cherry-pick).

• 在冲刺/开发周期的每个开始时，发布管理器都会根据master创建下一个发布分支。例如，release-sprint-42在创建时等于master分支。
• 开发人员使用来自develop 的基础创建功能分支。一旦准备好进行测试，他们就会合并功能分支以进行开发等。就像你目前建议的那样。
• 如果功能“正确”并且可以正常工作，则通过将功能分支合并到develop 中创建的合并提交将与release-sprint-42 中的-m选项一起挑选，例如. 在这里，知道您选择哪个父级非常重要（在我的示例父级 1. 开发人员应该阅读并理解http://git-scm.com/docs/git-cherry-pick）。git cherry-pick -m 1 COMMIT_HASH

Thoughts:

想法：

• Danger could be, that a feature working in developbranch might not work in release-sprint-42branch, because of missing dependencies. This, thank God, is why we have staging environments and internal deadlines :)
• Cherry-picking is not the easiest thing to do. But definitely the best way to try to avoid dragging unwanted code through a merge into a wrong branch.

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

Round up

围捕

Which is the best choice for you, depends on how you are developing. If you have 2 tracks, like "daily support-stuff" and "my big feature scheduled for release this December", you might go for 2 branches. If the long-term development is not 1 but several things and an on-going thing (i.e. if you usually have a lot of tasks, that span over multiple sprints/cycles), I would go for option 2.

哪个是您的最佳选择，取决于您的发展情况。如果您有 2 条轨道，例如“每日支持的东西”和“计划在今年 12 月发布的我的重要功能”，您可能会选择 2 个分支。如果长期发展不是一件事而是几件事和一个持续的事情（即如果你通常有很多任务，跨越多个冲刺/周期），我会选择选项 2。

Ideally, though, I would per default recommend a strategy, where stuff is broken down into small enough pieces and sprints are big enough, that a task/feature usually can be concluded (i.e. merged and deployed!) within 1 sprint. But from experience I know, that wishful thinking seldomly can be implemented :)

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

1 last thing: I would REALLY really reallyencourage you to not have 1 release branch (perpetual), but to create a new release-branch for each sprint/cycle, like release-sprint-42, release-sprint-43, et.c. (whether you base it off develop-branch in ideal git flow or off master-branch in the second scenario, I've suggested). Having perpetual release-branches often in my experience leads to missing stuff, merge-problems and other badness. Other than that, masterand developshould be perpetual-branches.

最后一件事：我真的真的真的鼓励你不要有 1 个发布分支（永久），而是为每个冲刺/周期创建一个新的发布分支，比如release-sprint-42、release-sprint-43等。 C。（无论您是在理想的 git 流中基于开发分支，还是在第二种情况下基于主分支，我都建议）。根据我的经验，拥有永久的发布分支经常会导致丢失的东西、合并问题和其他坏处。除此之外，master和develop应该是永久分支。

Looking forward to this discussion :)

期待这个讨论:)