Improving our GIT workflow

Our team have been using Git (in combination with Bitbucket) from the beginning of the project but no real workflow was explicitly defined. We were facing the occasional merge problems that happen when you don’t pay enough attention to what you’re doing with your branches, and not really using Git to it’s full potential.

After some painful merges (if you ever used Git inside a team, you know what I’m talking about) we decided to see what we could do to improve our workflow and use Git in a more collaborative way. The things that seemed the most important for us to improve were:

• the way we were handling branches for the development of new functionnalities
• having a clear Git history (for exemple for when we needed to cherry pick from one version of the application to another)
• use more of the functionnalities offered by Git and Bitbucket to improve our team efficiency and productivity

HANDLING BRANCHES

We create a branch for each separate new functionnality. It allows us to test the functionnality by building the branch inside a docker container and perform basic tests before merging the branch and mark the user story as ready to be tested by our product owner.

To manage this branches we defined a set of rules to reduce merge problems :

• force ourselves to update the branch with the changes from master as often as possible: in my opinion, that is the most important rule every team should follow to avoid merge conflicts nightmares after letting the branch diverge for too long
• use rebase to avoid polluting history with unecessary merge commits
• squash the commits made on the branch before merging : that way only one commit is merged onto master. The history is cleaner and cherry picking commit is made easier.

PULL REQUESTS AND CODE REVIEWS

Since we had a branch for each functionnality, we decided to use pull requests to perform code reviews before merging branches.

Bitbucket pull request mechanism allows us to notify the developers team for each new pull request and add comments on the code of the branch. Each pull request have to be approved by another member of the team before the code can be merged onto master.

Performing code reviews helped us improve the quality of our code and our team efficiency by allowing us to detect some mistakes earlier in our process and forcing us to respect the code standards defined by the team.

SUMMARY

Setting up those rules helped improve our global development workflow by unifying the way Git and branches were used by the team, cleaning our history and forcing us to pay more attention to the quality of the code merged into master. In my opinion, setting up some sort of convention on version control to be followed by the team is important to avoid wasting time on too many conflicts and improve productivity.