Stash Branching Model vs. git flow

[Johannes Kilian]

What are the reasons to introduce a "new" branching model (at least no identical naming with gitflow) within Stash 2.8?

As far as I understood from reading yet, Stash seems to support a branching model not identical with git flow (as supported by Atlassian Sourcetree); at least I do not understand how to configure Stash branching model to meet gitflow ...

I'm refering to following documentations: Using branches in Stash and A successful Git branching model

• branches \Release: Within Stash those are defined as "Release branches are used for release task and long-term maintenance of software versions." - <=> gitflow: "Release branches support preparation of a new production release."
• master branch: Within Stash, master is not mentioned explicitly <=> git flow: "We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state."
• production branch: Stash: The production branch is used while deploying a release. It branches from, and merges back into, the development branch. In a Gitflow-based workflow it is used to prepare for a new production release. This branch does not exist explicitly in gitflow - but from description it seems to correspond the gitflow\Release-Branches ("In a Gitflow-based workflow it is used to prepare for a new production release.")

Summary: gitflow\Release branches seem to be identical to stash\production branches. Stash\Release branches are not directly available within gitflow- it looks like Stash\Release branches correspond "multiple gitflow\master branches". The Stash\Release branches feature was always missing in gitflow in my eyes.

Now my question: How to configure Stash branching model to meet gitflow exactly? How to configure Sourcetree-gitflow to meet Stash branching model?

Refers to: Stash 2.8.1 / Sourcetree Windows 1.2.3.0

[jhinch (Atlassian) · Accepted solution]

Stash's branching model is highly flexible and can definitely be made compatible with gitflow. Use the following configuration:

• Development branch - develop
• Production branch - master (select use default branch)
• Bugfix branches - Not required. Uncheck
• Feature branches - Leave as is. feature/ is correct
• Hotfix branches - Leave as is. hotfix/ is correct
• Release branches- You have three options here and it depends how you use gitflow
  • You only use release/ branches in preparation for a release and not for on going maintenance (for patch version releases) then you can optionally enable the release branch version type. You won't really get much benefit from it being enabled
  • You use release/ branches for both preparation and ongoing maintenace for release. In this case you want to leave it enabled as it. release/ is correct
  • You use release/ branches for preparation of a release and support/ branches for ongoing maintenace. In this situation you want to change the release branch prefix to support/ in Stash

Gitflow release/ branches are pre-release preparation branches where as Stash's definition also incorporates post-release on-going maintenance (patch version bug fixes). Gitflow flow kind of has this concept by using support/ branches. However it is not clear if this is what support branches are used for as support they are not very well documented and are still experimental.

As of 2.8 Stash doesn't make heavy use of the branching model. It doesn't enforce that developers use the different branch types. It currently uses them for branch creation via the Stash UI as well as to control the flow of automatic cascading merges of release branches.

[Johannes Kilian]

What about gitflow release/ branches? I made use of them, but did not find it in your suggested mapping from Stash branching model to gitflow ...

Stash release/ branches is the one big missing feature within gitflow (in our environment we've got a couple of customers with different versions. Fixing a certain customer-version shows the need of Stash release/ branches)

[jhinch (Atlassian)]

If you are making point releases on release/ branches then you can use release branches in Stash. As I mentioned gitflow promotes that a release branch be deleted when the release is performed. If you are not doing this you can absolutely use Stash's branching model with release branches using the release/ prefix (instead of support/) and then even make use of our cascading merge feature which merges pull requests to downstream release branches

[jhinch (Atlassian)]

I've added some clarification into my answer. I hope this helps

[Scott Merritt]

We're using the release/ branches, but still, "how do I get it to automerge approved pull requests to the develop branch?" This is still the issue that I'm scratching my head about. Maybe this isn't possible. We're using the branches... but doesn't seem like it will merge stuff down to develop without me merging it manually or creating a pull request and going that route.

[Jens Schumacher [Atlassian]]

This article might help you understand how we work internally with the branch model:

http://blogs.atlassian.com/2013/10/inside-atlassian-feature-branching-on-the-stash-team

[Scott Merritt]

So your suggestion is to ditch gitflow so that I instead use release branches that always have a version number on them to get the automerge to work, since Stash doesn't seem to have a way to enble automerging to develop?