Simplified Git Flow

Branch it, tag it, release it, merge it

Geshan Manandhar

Quality and Maintenance Lead, Namshi.com

@geshan

geshan.com.np

Index

• Prerequisites
• Start a feature or bug fix on a new branch
• Work done, lets push
• Pushed the code? Let's open a merge/pull request
• Team Lead reviews code
• After review is ok, code is deployed to staging then live
• How to name tags
• Merge the tag to master when all tests are fine
• Things to consider
• Conclusion

Prerequisites

• You are aware of what git is, what it does and its benefits
• You know about basic git commands like add, commit, branch etc
• Master is the stable branch which can be deployed anytime
• You have already watched the git happens video.

Start a feature or bug fix on a new branch

• Always follow a naming convention when create new branch
• Like: OP-21 (where OP is short for OpenData and 21 is the ticket id from redmine/trello)
• Always get the latest master branch before you start any issue
• By typing: git checkout master && git fetch && git pull --rebase origin master
• Then get a branch out of the latest master
• The command will be: git checkout -b OP-21
• Now you can start working onf OP-21 - add blog content type

Work done, lets push

• So you finished working on OP-21
• Then you do the following to commit the changes:
• git add .
• git add -u - if files have been deleted
• git commit - then write a commit message
• Keep in mind commit messages need to be meaningful
• You can do multiple logical commits.
• git push origin OP-21

Pushed the code? Let's open a merge/pull request

• It is recommended that you squash your commits to single one
• To a merge request, always get latest master then rebase your branch
• Be in your branch git checkout OP-21, then execute: git rebase master.
• As you just rebased with master, you may need to force push : git push -f origin OP-21
• Browse to gitlab open a merge request
• Put the issue in right status/column on redmine/trello and put the merge request link in the comment.

Team Lead reviews code

• Team/Project Lead should always check and review code for each pull/merge request
• Code review is done to ensure coding standards, coding and naming conventions.
• It is also done to ensure code is maintainable on the long run.
• If there are comments, it needs to be addressed by the software engineer by re-working.
• If the code matches standards, does the work and tests are passing it can be deployed.

After review is ok, code is deployed to staging then live

• First deployed to Staging
• For staging, its ok to deploy the branch with a deployment process.
• If all tests are fine, then code is deployed to live.
• For live/productions, always create a tag and deploy the tag
• Given you are on OP-21 branch, execute git tag 1.11.2
• Then push the tag: git push origin 1.11.2 and deploy it live

How to name the tags

• Tags are basically pointers to a particular commit
• Naming depends on the version conventions.
• 1.11.2-p0 can mean 1st Year of operation, month of November, date is 2 - p0 for second release of the day
• 1.44.3 can mean 1st Year of operation, week no. 44 and release no 3, if you follow weekly sprints.
• If you use tags for staging you could suffix it with rc-1, rc for release candidate

Merge the tag to master when live is stable

• After testing and monitoring the live deployment, tag can be merged to master
• To merge the tag to master, get the latest master
• Then run: git merge --no-ff 1.11.2 know why --no-ff
• All the changes that were deployed are in master right now
• Then you can deploy another branch after tagging it.
• Next tag for the same day will be 1.11.2-p0
• Here p0 means patch 0 or 2nd deployment of the day.

Things to consider

• Never force push on master
• You can force push on your branch provided others have not branched out from your branch.
• If tickets/issues are related, you can branch out from a different branch than master
• If you branched out of OP-10, you can send a merge/pull request to OP-10 as well.
• Always align your branch from your source branch which is generally master.
• Hot-fix branches have not been covered.

Conclusion/Recap

• Git flow is easier than it looks, with single ticket deployments.
• Git flow encourages rigorous code reviews.
• It helps to follow a standard procedure.
• Rollbacks are easier as you know the last deployed live tag.

Credits

• http://hades.name/blog/2010/01/22/git-your-friend-not-foe-vol-2-branches/
• https://www.flickr.com/photos/oberazzi/318947873/