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

Simplified gitflow has only one perpetual branch master which decreases the complexity, only one ticket can be deployed and tested in any given environment like staging or production. When only one ticket is deployed on a given environment, it is very easy to trace a problem if it occurs. As the full gitflow, master is the stable branch which can be deployed to production anytime.

Transcript

1. Do you git your code? Follow simplified Gitflow branching model to improve productivity By: Geshan Manandhar
2. 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
3. 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
4. Not using Git in 2016, Why?
5. Wrong tool for the job
6. Git is super popular
7. 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
8. Everyone in the team is pushing to master, Why?
9. When everyone pushes to master, someone will fall in a hole
10. Tell a story with your commit/branch history.
11. 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
12. 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
13. 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
14. 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
15. 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
16. 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
17. 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
18. 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
19. 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.
20. 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.
21. DEMO Let’s see how to do it
22. 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.
23. 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
24. 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
25. 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
26. 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/