Branch Management with Bitbucket

[#1]

As a project manager, I have discovered that different developers want to bring their previous branching method with them when they join the team. Some developers are used to performing individual work, branching from and merging right back into the master branch. Others have worked on large teams where old branches were never cleaned up, leaving thousands of stale branches along the way. This can really create some otherwise avoidable issues. Fortunately, Bitbucket makes branching, comparing file changes, merging, and cleanup an easy task.

It’s important to involve the whole team, get feedback, decide on the best branching method moving forward, and work on getting wall-to-wall buy-in. Create a branching workflow diagram, explain it to your team, and, as you are getting started, require merge approvals. Require approval. It will keep new users and old from merging when they shouldn't and where they shouldn't, ultimately making for a happier team.

My team agreed that we needed a model that would allow us to continuously fix bugs while developing new features and keep a clean branch for production while we ran alpha and beta tests. Pretty straightforward criteria for a team of app developers. We decided that the master branch would be our clean “Production” branch and we would have our working “Development” branch stem from it. On a daily basis developers branch from the Development branch to work on issues (Bugs from our Jira instance) or continue their work on new features and perform a pull request when they feel the task is complete. Once a sprint is completed, a branch from the Development branch is created for “Testing”. Work for the next sprint can continue on the Development branch and “Beta Bug Fixes” can be made on the Testing branch. When all testing is completed the Testing branch is pulled into the Development branch if any Beta Bug Fixes were made and then it is merged to the Production branch. Otherwise, development continues on its branch, the Testing branch is merged to Production and the Testing branch is removed.

[timhoustontx]

Interesting.

what if you need to apply a critical bug fix to the production branch?  

do you re-do the whole process?

We have multiple release branches in use by different users.  bug fixes in some must merge up to other branches.  Our release branches seem to correspond to your production branch.  Each individual contributor creates their own development branch which is then merged to the production version branch after a pull request is approved.  Then those changes are merged up to other branches till it reaches the master branch.  This approach has its strengths and flaws.  

[Jonny Adams]

@timhoustontx Critical fixes are pretty rare in my experience with this team. We alpha test, then expand our in-house beta, and finally roll a beta out to a team within our customer base before moving a build to production. 

It isn't in our workflow, but I believe in a case where a critical bug fix is needed we simply branch from production, make the fix & merge back to production, and ship it. Then we incorporate the bug fix into the ongoing development branch and continue the sprint.

[Gary Miner]

Another scenario we find ourselves is that the critical bug fix has already been completed in development. So we cherry-pick the commits from development onto the production branch. 

[Vernee Green-Myers]

Has anyone used #bitbucket-cloud for Development with Salesforce?  

[Eric Wersel]

The critical fix is "Aa" and is merged to production immediately after testing, without requiring anything from the development branch. "D" is merged into production as part of the regular release cycle sometime after the critical patch is already in production.

[Eric Wersel]

@Vernee Green-Myers you should probably ask your question at https://community.atlassian.com/t5/Bitbucket-questions/qa-p/bitbucket-questions since it's specific to Bitbucket, but not this branching article.

[ralvy]

This seems to be the GitFlow (or HgFlow) model, exactly.

[Erick Massa Sprengel]

as @ralvy said. It's the git-flow.
There is a good reference on atlassian tutorials:  https://www.atlassian.com/git/tutorials/comparing-workflows

I applied it using pull requests on this example:  https://github.com/ericksprengel/git-flow-test/network

The displayed tree is not so good on github. I did 2 things:
- 1 hotfix
- 1 release

You can also check the original git flow post: https://nvie.com/posts/a-successful-git-branching-model/

[Adrian Sweeney]

We have locked the master branch down so you can't manually commit to it which is working fantastically for us.  A real pain in the arse for me but I got used to it quick enough.

If you need to do a hot fix you do it in a hot fix branch then create a PR and click merge to push to master.  The system messages everyone that a PR was created (via slack) so even if you don't tag people to review it they get notified anyway and can check out the hot fix.

[MsWebGirl]

I love this idea.  I'm going to incorporate this process.