Skip to content

On branching strategy of this project

Jump to bottom
Burke Chih-Jen Ko edited this page Feb 9, 2017 · 1 revision

As features are getting implemented, very often we have various components at an immature stage on the master branch. Build using the same branch to the production site means these unfinished features will be exposed with various potential problems.

I am introducing a branching strategy here for us to implement in our daily development activities:

  1. We have 4 branches that should always be there: master, dev, uat and prod.
  2. Our work-in-progress should always be commit to master branch or our personal short-living branch then merge to the master one.
  3. Between our working branch and master merging can happen bidirectionally.
  4. For staging to dev, uat, prod, merge can only happen in one direction.

Below is an example workflow illustrates how it works. However, please read the basics before continue.

Branching strategy graphics

On the top of the figure is a simplified commit history that normally goes on our master branch.

  • At a point, Roger committed B ① then Pete committed C ② in his own feature branch, at the same time Roger continued to work on D ③.
  • When Roger committed E ④ and thought that his work is ready, he then merge to master to form the commit F ⑤.
  • After a new commit G ⑥, Pete decided to do a dev build, so while on master branch, he:
$ git checkout dev
$ git merge master
$ git push
  • Jenkins detects the change on the dev branch and build automatically. At this time, dev has commit G as the latest ⑦. Pete then switch back to the master branch and continue working.
  • Two days later, Pete thought that feature seemed stable and no further feedback needed to address, so he further staged commit G to uat⑧:
$ git checkout uat
$ git merge dev
$ git push

And later, to prod⑨:

$ git checkout prod
$ git merge uat
$ git push
$ git checkout master
  • Roger, following Pete, made commit H & I⑩, and pushed the new commits to dev.

The story goes like this. Team members keep contributing new commits to the master branch and when feasible, staging to dev, uat, and eventually to prod. Once commits got staged to dev, they never get staged back to master, so it's only one direction.

Technically speaking, one can merge any two branches from either direction, but we should follow this to ensure that the status on uat and prod are always relatively stable, therefore anyone can trigger the prod build without worrying it contains other developer's experimental feature.

Clone this wiki locally