release vs feature in git flow

Question

Since both are ultimately children of the development branch, what is the intended use of a release vs a feature when using the smart branching tools?

I'm setting up a respoitory for applications developed on top of an vendor's database product.  This product has a build promotion stream with 3 environments; POC, Test and Production.  We connect to the POC environment for development projects, and we need to do integrated testing before promoting anything to the Test environment.  My first thought was to let the development branch correspond to the code in Test and to always have a release branch active to track the code in POC (ie, finish the release when code moves into Test, then immeidatley start the next one to catch the next round of changes).  I initially thought that features would be children of the active release and they could be used to further quarantine changes that weren't ready for full integrated testing, but found that finishing a feature merges the code into the development branch instead.

I can do what I want by manually creating a branch and merging it into the release when I'm done with it, but I'm not sure now what the purpose of a release vs feature is since they are structurally identical.  Based on the names, I expected a release to be a collection of features.  As they are, I don't see any difference between the two.

Thanks.

KieranA · Accepted Answer

Hi Jon,

This isn't really related to SourceTree as we support git-flow by issuing commands to it, we don't implement our own flow logic. To answer the question though there are subtle differences between release and feature branches but that's besides the point of the flow logic. The types of branches based on what git-flow command you're issuing are there to distinguish them in terms of your workflow. That is their purpose (although not their only purpose).

The subtle difference between the two is that feature branches have to merge back into develop whereas release branches must merge back into both developer and master. Feature branches usually only exist in the devs repo and not in origin, too. This is because you push your master branch changes mostly keeping your repo history clean.

So yes, feature branches are supposed to merge into develop because develop should reflect the most recent changes to the repository (after features are merged). Release doesn't reflect the most recent changes, develop does. Master is always in a "production-ready state".

Nope, feature branches should come off develop because otherwise you're branching off a state of code which isn't the most recent. Remember, "Release branches support preparation of a new production release". So if you branch from release you're branching from a place which is specifically there to prepare for a release and may not contain everything that's currently in develop as develop would've carried on after the release branch started. The commits in release from there on out would be to prepare it for a product release followed by merging it back into develop/master.

Hopefully that helps, let us know if you need anything clearing up though.