June 28, 2017
What’s in a name? Understanding parallel development with GitFlow—Part 1
By: Nicholas Gulrajani

My main reason for writing this blog was to start addressing some questions I have been recently getting from various project teams as to how to implement a parallel development model and how to apply parallel development model to an Apex-based Salesforce development.

Vincent Driessen wrote “A Successful Git Branching Model” in 2010 (kudos to Vincent Driessen for coining the term). Today, this model is as important as it was in 2010, and I have used it successfully on many projects that I have worked on. You can read the details here.

Summarizing the branching structure
The general idea of GitFlow is to follow these branching naming conventions in a Git repository of choice.

  • Development branch (aka, develop): This is your main development branch where all the changes destined for the next release are placed, either by directly committing small changes or by merging other branches (for example, feature branches) into this branch.

  • Production branch (master): This branch represents the latest released/deployed codebase, only updated by merging other branches into it.

  • Feature branches (feature): When working on anything non-trivial, a feature branch is created. When finished, this branch will be merged back into the development branch to queue it for the next release.

  • Release branches (release): When packaging a new release, a new release branch is created from the development branch where it can be committed to the release branch during the preparation for a release. Once it’s ready to be deployed, merge it into both the development branch and the master branch (to indicate that the release has been deployed).

  • Hotfix branches (hotfix): Once changes have been made, the hotfix branch is then merged back into both the master branch (to update the released version) and the development branch (to make sure the fixes go into the next release too).

Screen shots of the model below (Exhibits A and B) were implemented using Bitbucket along with an Eclipse Interactive Development Environment (IDE) with EGit as the client and all of the branching model described in the above summary.

Exhibit A—Parallel DevelopmentExhibit A—Parallel Development

Exhibit B—Eclipse IDE and GitFlowExhibit B—Eclipse IDE and GitFlow

In my next blog, I will show how we got there step-by-step so please stay tuned.

By focusing on these four major stakeholder groups, you can get a “360 degree of DevOps” to further your journey toward Lean IT.

Popular Tags

    More blogs on this topic



        COMMENTS (0)




        Your Data Privacy

        By providing your e-mail address, you agree to the terms
        outlined in our privacy statement associated with
        commenting on the site. Your e-mail address will not be
        used for promotional marketing purposes.

        Change the CAPTCHA codeSpeak the CAPTCHA code