开发者

Merging feature branches to release branch instead of trunk

I have a question about two source control scenarios, both with feature branches and release branches:

  • In scenario 1 feature branches are merged to the trunk.
  • In scenario 2 feature branches are merged to the latest release branch.

What are the consequences of scenario 2 compared to scenario 1?

What are the possible advantages and disadvantages of both scenarios?


More details of the two scenarios:

Scenario 1 (similar to what is described in this SO-answer):

  • feature branches are always merged to the trunk
  • a new release branch is created from the trunk, when preparations start for a new release
  • after QA and deployment from a release branch, the changes/bugfixes in the release branch are merged to trunk and newer release branches
  • changes to the trunk are merged to all feature branches

Scenario 2:

  • feature branches are always merged to the newest release branch
  • a new release branch is created from the trunk, when the current release branch no longer accepts new features and preparations start for final release
  • after QA and deployment from a release branch, the changes/bugfixes in the release branch are merged to trunk
  • changes to the trunk are merged to all feature branches and the newest release branch


Since branching is all about isolation (see "When should you branch), the difference between the 2 scenarios is the role you want the main branch trunk to have:

  • Scenario 2 is more adapted to a static role: trunk would be the representation of what is in production (and the occasional hot-fixes needed to be merge back to current feature and next-release branch)

  • Scenario 1 is more suited for a dynamic role: trunk is the integration for various feature, release branches being made from there to consolidate the features which will actually be part of the next release.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜