Note that there are some explanatory texts on larger screens.

plurals
  1. POWhy is merging feature branches into release branches a bad idea?
    text
    copied!<p>We have adopted the branching model proposed by <a href="http://nvie.com/posts/a-successful-git-branching-model/" rel="noreferrer">Vincent Driessen</a> and we do nearly everything as he has described in his <a href="http://nvie.com/posts/a-successful-git-branching-model/" rel="noreferrer">article</a>.</p> <p>Only when it comes to handling release branches we deviate a bit.</p> <p>Vincent proposes to develop features in branches which are branched from the developer. When it is decided which features come into the next release, they are merged back into the developer and a release branch is created from it.</p> <p>After that the feature branch should only be used for testing and bugfixing. When the release is deployed to live, the release branch is merged back into developer and master.</p> <p>What we do instead is to merge features directly into the release branch: <img src="https://i.stack.imgur.com/J4QQd.png" alt="realease branch modelling"></p> <p>I feel that this is not the way it should be done and I'm trying to think of cases where this could actually make things more complicated.</p> <p>One I can think of is the following:</p> <p>Let's say a new <strong>Feature c</strong> is building upon <strong>Feature a</strong>, which is already merged into a release branch. I have to first merge the release branch back into the developer to be able to create a new <strong>Feature c</strong> branch from developer.</p> <p>Are there other cases where this branching model could make things more complicated?</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload