Do You Git Your Code? Follow Simplified Gitflow Branching Model to Improve Productivity

Do you git your code?
Follow simplified Gitflow branching
model to improve productivity
By: Geshan Manandhar

HELLO!I am Geshan Manandhar
Senior software Engineer | QM Lead at Namshi.com
Tech Solution Provider
Agile follower and conditional microservices believer
@geshan - Geshan.com.np

What is this talk about
◉ Why Git and simplified git flow a.k.a github flow
◉ Prerequisites and assumptions
◉ The simplified gitflow/github flow steps
◉ Demo
◉ Things to consider
◉ Recap and Conclusion

Git Usage in Nepal
Git is the most popular
VCS in Nepal
◉ 82.22% respondents of
a survey I did in 2015
said they used git.
◉ Survey: bit.ly/nep-dev-
survey
◉ Results as infographics
on my blog

Everyone in the team is
pushing to master,
Why?

When everyone pushes to master, someone will fall in a hole

Tell a story with your
commit/branch history.

Prerequisites
◉ You are aware of
◉ what git is
◉ what it is used for
◉ benefits of git
◉ You know about basic git commands like add, commit,
checkout etc
◉ Master is the stable branch which can be deployed anytime

Step 1: Start working in feature or bug fix - get a new branch
◉ Always follow a naming convention when you create a new
branch
◉ Like: HK-16 (where HK is short for project Hookah and 16 is the
ticket id from redmine/trello/Jira/Github Issue)
◉ 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 HK-16
◉ Now you can start working on HK-16 - change readme

Step 2: Finished coding, let’s push now
◉ So you finished working on HK-16
◉ Then you do the following to commit the changes:
◉ git add . (explore git add -p)
◉ 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 HK-16

Step 3: Pushed Code, now open a pull/merge request
◉ It is recommended that you squash your commits to one
◉ To open a merge/pull request, always get latest master then
rebase your current working branch
◉ Be in your branch git checkout HK-16, then execute: git
rebase master.
◉ As you just rebased with master, you may need to force push :
git push -f origin HK-16
◉ Browse to github/gitlab open a pull/merge request
◉ Move issue to right status in your project management
software if needed

Step 4: Team Lead/member reviews code and adds comments if needed
◉ Project Lead/Member should always check and review code
for each pull/merge request
◉ Code review is done to
◉ ensure coding standards
◉ coding and naming conventions
◉ any obvious bugs
◉ the solution quality is up to the standards
◉ code is maintainable on the long run.
◉ If there are comments, software engineer needs to fix them
◉ If the code matches standards, works and tests are passing :
deploy

Step 5: Code review ok, deploy to staging/production
◉ Always deploy to staging first and test it
◉ For staging, its ok to deploy the branch with your deployment
process
◉ If all (manual) tests are fine, then code is deployed to live.
◉ For live/productions, always create a tag and deploy the tag
◉ Given you are on HK-16 branch, execute git tag 1.6.25
◉ Then push the tag: git push origin 1.6.25 and deploy it live

Why is the tag named 1.6.25?
◉ Tags are basically pointers to a particular commit
◉ Naming depends on the version conventions.
◉ 1.6.25-p0 can mean 1st Year of operation, month of June, date
is 25 - 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
◉ Naming tags depends on how you want to do it

Step 6: Merge the tag to master when production/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
◉ On master branch run: git merge --no-ff 1.6.25
◉ All the changes that were deployed are in master right now
◉ This will automatically close the pull/merge request of the
branch
◉ You can deploy another branch after rebase and tagging it
◉ Next tag for the same day will be 1.6.25-p0
◉ Here p0 means patch 0 or 2nd deployment of the day

Why do a --no-ff on merge
◉ The --no-ff flag causes the merge to
always create a new commit object,
even if the merge could be performed
with a fast-forward.
◉ This avoids losing information about
the historical existence of a feature
branch and groups together all
commits that together added the
feature.

Difference between Gitflow and Simplified Gitflow
Basis Gitflow Simplified Gitflow
Perpetual
Branches
Has 3 perpetual branches:
master, release, develop
Has only 1 perpetual branch: master
(always stable, always deployable)
Complexity Higher: as Release needs to be
rebased with master and
develop. Conflicts can occur.
Lower: as there is only one perpetual
branch “master”, if all is good issues are
merged to master
Deployment
Atomicity
Multiple issues/tickets can be
deployed at a time. PRs merged
to release branch and tag
created from release to deploy.
Only one issue/ticket can be deployed at
a time. Atomic deployment helps in
testing and rollback is easier.

Things to consider
◉ Never force push on master
◉ You can force push on your branch provided others have not
branched out from your branch.
◉ For dependent issues, you can branch out of OP-10 then send
a merge/pull request to OP-10.
◉ Always align your branch from your source branch which is
generally master.
◉ Hot-fix can be done in the same way.

Simplified Gitflow/Github flow Recap
1. Start working in feature or bug fix - get a new branch
2. Finished coding, let’s push now
3. Pushed Code, now open a pull/merge request
4. Team Lead/member reviews code and adds comments if
needed
5. Code review ok, deploy to staging/production
6. Merge the tag to master when production/live is stable
7. You are a workhorse, work on the next issue

Conclusion
◉ Simplified Git flow is easier than it looks, with single ticket
atomic 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 or
if tag is not merged it’s always safe to depl

THANKS!
Any questions?
You can find me at
@geshan - Geshan.com.np
◉ Looking for a job change? http://bit.ly/it-job-change-np
◉ This slide available at: http://bit.ly/s-gitflow

References
◉ http://vimeo.com/46010208 - Git Happens Video
◉ http://nvie.com/posts/a-successful-git-branching-model/ - Gitflow Brancing Model
◉ http://chris.beams.io/posts/git-commit/ - writing good commit message
◉ http://geshan.com.np/blog/2014/07/4-git-tips-beyond-basics/ - 4th Tip on Squashing git
commits
◉ http://geshan.com.np/blog/2016/04/3-simple-rules-for-less-or-no-git-conflicts/ - Be less
prone to git conflicts
◉ Images below:
◉ http://devopsreactions.tumblr.com/post/134848252538/when-the-backend-team-gets-
stuck-behind-schedule
◉ http://devopsreactions.tumblr.com/post/129836686205/wrong-tool-for-the-job
◉ https://unsplash.com/photos/G6G93jtU1vE
◉ https://www.flickr.com/photos/62244271@N03/8553590682/sizes/l
◉ https://pixabay.com/en/primate-ape-thinking-mimic-view-1019101/

Do You Git Your Code? Follow Simplified Gitflow Branching Model to Improve Productivity

Recommended

More Related Content

What's hot (20)

Similar to Do You Git Your Code? Follow Simplified Gitflow Branching Model to Improve Productivity (20)

More from Geshan Manandhar (20)

Recently uploaded (20)

Do You Git Your Code? Follow Simplified Gitflow Branching Model to Improve Productivity