Background Problem
For sharing session in UNIKOM CodeLabs division, I will share my story about how to make a good git branching model. I’ve been using Git since 3 years ago. I usually just create one branch called master (You must be familiar with it). Everything is fine when I work alone. There is different story when I work with the team. Too much code conflict, uncounted pull, integration error are some problems with just one branch exist. When I was suffering and trying to looking for solution, I found a good reference. Thanks to nvie.com that give me inspiration how to make a good branching model.
Based on My Experience
I’ve tried some git branching model. Check the list below.
-
Push everything to master
This model has many problems in its implementation. As I mentioned first, the problems are too much code conflict, uncounted pull, integration error.
-
Create a branch based on name of team member (Firman branch, Bayu branch, Rizal branch, etc).
This model has weakness that is the part of job/feature for everyone must be clear in the first of development cycle.
A Good Git Branching Model
There are two type of branch, main branch and supporting branch.
-
Main Branch
Main branch consist of
masteranddevelopmentbranch.masteris branch for production state and `development’ is branch for development state. -
Supporting Branch
I’ve decided to make some supporting branch that will help optimizing main branch. Supporting branch consist of
featureandhotfixbranch.featurebranch is a per-feature branch (ex: feature/home_timeline branch) that copied fromdevelopmentbranch and will merge back todevelopmentbranch after the feature have finished.hotfixbranch is a branch that will be created if bug encountered in production state and must be resolved as soon as possible.hotfixbranch is copied frommasterbranch, after the bug is resolvedhotfixbranch will merge back tomasterand merge todevelopmentbranch too.
Presentation File
I’ve created a powerpoint for this. here it is, hope you enjoy.