Git Branching Strategy

Owned by KevinPalis
Last updated: May 04, 2020
2 min read

For years our git branching strategy have been based on the gitflow workflow. With GOBii’s integration with EBS, we will make some changes to our branching strategy. However, main workflow will still be gitflow.

 

The main motivation for these changes is because we now have to keep two code bases:

  1. Stand-alone GDM - This will contain all our 2.2 code and any other changes (hotfixes, bug fixes) that are not asked for by EBS.

  2. EBS-GOBii - All the integration work and all future releases of GDM will be in this code base. Release/2.2 is the last major release of GDM outside EBS, all future releases will be within EBS, starting with EBS v3.

With these code bases in mind, I will try to outline the branching strategy we agreed on:

  • Gitflow workflow mentions 2 main branches that track history: master and develop. With our changes we will have 3:

    • ebs_develop = renamed from the old “develop” branch, this will contain all historical changes and new GOBii-EBS changes and features

    • standalone_develop = branched out from release/2.2, this branch contains non-EBS GOBii changes, bugfixes, and hotfixes.

    • master = same branch as it’s always been (based on the definition from the gitflow workflow). This contains the latest stable release. After release/2.2, all releases will now be under EBS starting with EBS 3.0.

 

I tried to visualize all these in the diagram below. Please note that the blue branch (master) can be tracked by a Bamboo plan branch for the EBS-GOBii CI/CD pipeline (green box) if we see the need to do so.

 

 

After October 2020, GOBii will be fully merged with EBS, the yellow box (old pipeline) and the yellow line (standalone_develop) will be on a run-and-maintain status, ie. no features, only bugfixes and hotfixes for old clients.