Git and Git Workflow Models as Catalysts of Software Development

This is the slides of my latest talk in DevFest Istanbul 2013 which is organized by Google Developers Group Istanbul. The content mainly has 3 sections. Git branching model in theory, creating a feature by git commands and git best practices.

Transcript

1. AS CATALYSTS OF SOFTWARE DEVELOPMENT Lemİ Orhan ERGİN lemiorhanergin.com @lemiorhan @lemiorhan GIT & GIT workflow MODELs
2. Lemİ Orhan Ergİn Principal Software Engineer at Sony has worked in Tüsside, BYM, GittiGidiyor/eBay and Sony as lead developer, technical leader, technical coordinator and scrum master using Git, but not an expert organisational level SVN to GIT migration projects experienced so far doing code reviews as a daily habit experienced in agile transformation and building agile culture in teams & organisations 2001 2013 2009 2 2005 agile CSM, PSM1 0.5M total number of views of his presentations
3. I love git
4. I love git because… I used SVN for a while Local branching is cheap Everything is local Distributed Small and efficient Any workflow Lightening Fast Huge community GitHub… Thanks God! More than 3M people˝ More than 5M repositories˝ Raised $100 million on July'12 Ruby on Rails with full history and branches weight 13Mb.
 It weights 115Mb in SVN Each object is compressed by zlib and transferred over wire one by one
5. git data model is It is a directed acyclic graph Objects (blob, tree, commit, tag) are immutable References (branch, remote) always change hot
6. It is not a magical version of SVN. Try to understand what it's actually doing. Stop comparing SVN with GIT
7. “ I really really designed it coming at the problem from the viewpoint of a file system person, I actually have absolutely zero interest in creating a traditional SCM system. It's a stupid content tracker. 
 It tracks files and folders. ” LINUS TOVALDS
8. git changed the way we think of merging branching workflows
9. git is a tool for designing vcs workflows
10. git workflow model main branches supporting branches Feature development release development hot fixes in production
11. which are created at the very beginning main branches are permanent branches and never deleted! main branches
12. test & QA STAGING & UAT Production development MASTER It reflects the latest delivered development changes for the next release Automatic nightly builds OPTıONAL main branches
13. test & QA STAGING & UAT Production development MASTER It reflects the code which is deployed to test/qa environment for testing Automatic nightly builds Automatically deployed to test/qa servers every night OPTıONAL main branches
14. test & QA STAGING & UAT Production development MASTER It reflects the code which is deployed to staging/uat environment for testing Automatic nightly builds Automatically deployed to test/qa servers every night Automatically deployed to staging servers every night OPTıONAL main branches
15. test & QA STAGING & UAT Production development MASTER It reflects the code which is deployed to production Automatic nightly builds Automatically deployed to test/qa servers every night Automatically deployed to staging servers every night Automatically deployed to production servers on demand OPTıONAL main branches
16. and will be removed eventually These have limited life time supporting branches feature branches HOTFIX branches release branches
17. and strict rules for originating and target branches These have specific purpose supporting branches feature branches HOTFIX branches release branches
18. All feature branches should be created from The development branch the next release branch Feature development
19. take a new feature branch regardless of the feature size you can fix very minor common issues directly in development branch, like fixing typos Feature development
20. Feature development Feature 1 Feature 2 Feature 3 development Next Release 2 Feature 2 is completed and ready for the next release
21. Feature development Feature 1 Feature 2 Feature 3 development 1 Next Release 2 Feature 1 is being developed
22. Feature development Feature 1 Feature 2 Feature 3 development 1 D Next Release 2 Feature 2 is completed and merged back to master
23. Feature development Feature 1 Feature 2 Feature 3 development 1 D 1 Next Release 2 Feature 1 gets the commits in Feature 2
24. Feature development Feature 1 Feature 2 Feature 3 development 1 D 1 1 D Next Release 2 Pulls all the commits from other features and resolve conflicts
25. Feature development Feature 1 Feature 2 Feature 3 development 1 D 3 1 1 D Next Release 2 Feature 3 is created from development. It has commits of Feature 2
26. Feature development Feature 1 Feature 2 Feature 3 development 1 D 3 1 1 D Next Release D 2 Feature 1 is completed and merged back to master
27. Feature development Feature 1 Feature 2 Feature 3 development 1 D 3 1 1 D 3 Next Release D 2 Feature 3 gets the commits of Feature 1
28. Feature development Feature 1 Feature 2 Feature 3 development 1 D 3 1 1 D 3 Next Release D D 3 2 Feature 3 pull updates frequently
29. Feature development Feature 1 Feature 2 Feature 3 development 1 D 3 1 1 D 3 Next Release D D 3 D 2 Typo is fixed directly in development branch
30. Feature development Feature 1 Feature 2 Feature 3 development 1 D 3 1 1 D 3 Next Release D D 3 3 D 2 Feature 3 pulls commit about fixing the typo
31. Feature development Feature 1 Feature 2 Feature 3 development 1 D 3 1 1 D 3 Next Release D D 3 3 D D 2 Feature 3 is completed and merged back to master. It has commits of all 3 features now.
32. Release branch is created when all features are ready for the next release sometimes we call it as feature freeze release development
33. Release branch is deleted when the release completes we will tag the released code, no need to keep the branch.. release development
34. release development development release Production MASTER D D F F Completed features are merged with development Next Release
35. release development development release Production MASTER D D D F F All features are ready for the next release Next Release
36. release development development release Production MASTER D R D D F F Start a release branch when features are freezed Next Release
37. release development development release Production MASTER D R R R D D D D F F Only fixes are allowed Bug fixes are continuously merged back to development brach Next Release
38. release development development release Production MASTER D R R R R D D D D F F Release is ready now Next Release
39. release development development release Production MASTER D R R D R R D D D D F F Latest fixes are merged back to development branch Next Release
40. release development development release Production MASTER D R M R D R R D D D D F F Merge release branch with master branch
 and get a new tag Next Release
41. Fix branches are required because every fix should be well tested and verified it means, you may need to rollback what you’ve done in the fix hot fixes in production
42. hot fixes in production development Hot-FIX Production MASTER Next Release M Hot fix is required! A new branch is created from production branch
43. hot fixes in production development Hot-FIX Production MASTER Next Release M H Fix is developed, tested and verified. Ready to go.
44. hot fixes in production development Hot-FIX Production MASTER Next Release M H D Hot fixes are merged back to development branch
45. hot fixes in production development Hot-FIX Production MASTER Next Release M H D M Hot fix is merged with production branch and production branch is tagged
46. This graphic is taken from Vincent Driessen’s article called 
 “a successful git branching model” ALL FLOWS IN THE MODEL
47. feature development
48. ➜ git:(master) git checkout -b development Switched to a new branch 'development' ➜ git:(development) git push origin development Total 0 (delta 0), reused 0 (delta 0) To UberProject.git * [new branch] development -> development ➜ git:(development) git branch -a * development master remotes/origin/development remotes/origin/master creatE permanent branches If these does not exist 1 it creates development branch from master and pushes to remote
49. Pull to update
 local development branch be sure you run tests directly afterwards 2 ➜ git:(master) git fetch origin From UberProject * [new branch] development -> origin/development ➜ git:(master) git checkout development Branch development set up to track remote branch development from origin. Switched to a new branch ‘development' ➜ git:(development) git pull remote: Counting objects: 19, done. remote: Compressing objects: 100% (8/8), done. remote: Total 17 (delta 2), reused 0 (delta 0) Unpacking objects: 100% (17/17), done. From UberProject 3eb8b34..c827c84 development -> origin/development Updating 3eb8b34..c827c84 Fast-forward grails-app/controllers/org/example/BookController.groovy | 6 ++++++ grails-app/domain/org/example/Book.groovy | 7 +++++++ test/unit/org/example/BookControllerTests.groovy | 17 +++++++++++++++++ test/unit/org/example/BookTests.groovy | 17 +++++++++++++++++ 4 files changed, 47 insertions(+) create mode 100644 grails-app/controllers/org/example/BookController.groovy create mode 100644 grails-app/domain/org/example/Book.groovy create mode 100644 test/unit/org/example/BookControllerTests.groovy create mode 100644 test/unit/org/example/BookTests.groovy
50. ➜ git:(development) git checkout -b feature-1185-add-commenting Switched to a new branch 'feature-1185-add-commenting' create a feature branch
 from development with a name having story id and descriptive title 3 the title should give hints about what’s in it ➜ git:(feature-1185-add-commenting)
51. work in your feature branch commit early and often 4 ➜ git:(feature-1185-add-commenting) vi web-app/WEB-INF/applicationContext.xml ➜ git:(feature-1185-add-commenting) ✗ git add . ➜ git:(feature-1185-add-commenting) ✗ git commit -m "added comment for applicationContext.xml" [feature-1185-add-commenting b6f68cc] added comment for applicationContext.xml 1 file changed, 2 insertions(+), 1 deletion(-) ! ➜ git:(feature-1185-add-commenting) vi web-app/WEB-INF/sitemesh.xml ➜ git:(feature-1185-add-commenting) ✗ git add . ➜ git:(feature-1185-add-commenting) ✗ git commit -m "added comment for sitemesh.xml" [feature-1185-add-commenting 0e74f89] added comment for sitemesh.xml 1 file changed, 3 insertions(+), 1 deletion(-) ! ➜ git:(feature-1185-add-commenting) vi .application.properties ➜ git:(feature-1185-add-commenting) ✗ git add . ➜ git:(feature-1185-add-commenting) ✗ git commit -m "increased the application version" [feature-1185-add-commenting 7ce1f07] increased the application version 1 file changed, 1 insertion(+), 1 deletion(-) Be careful! it does not mean “push early and often”
52. rebase frequently
 to incorporate upstream changes to prevent your branch from diverging significantly 5 ➜ git:(feature-1185-add-commenting) git fetch origin development From UberProject * branch development -> FETCH_HEAD ➜ git:(feature-1185-add-commenting) git rebase origin/development First, rewinding head to replay your work on top of it... Fast-forwarded feature-1185-add-commenting to origin/development.
53. rebase frequently
 to incorporate upstream changes to prevent your branch from diverging significantly 5 ➜ git:(feature-988-add-shelf-controller) git checkout development Switched to branch 'development' Your branch is behind 'origin/development' by 2 commits, and can be fast-forwarded. (use "git pull" to update your local branch) ➜ git:(development) git pull Updating 4559eba..d55ee12 Fast-forward application.properties | 2 +- grails-app/domain/org/example/Shelf.groovy | 7 +++++++ test/unit/org/example/ShelfTests.groovy | 17 +++++++++++++++++ web-app/WEB-INF/applicationContext.xml | 3 ++- web-app/WEB-INF/sitemesh.xml | 4 +++- 5 files changed, 30 insertions(+), 3 deletions(-) create mode 100644 grails-app/domain/org/example/Shelf.groovy create mode 100644 test/unit/org/example/ShelfTests.groovy ➜ git:(development) git checkout feature-1185-add-commenting Switched to branch 'feature-988-add-shelf-controller' ➜ git:(feature-988-add-shelf-controller) git merge development Updating 7761c9c..d55ee12 Fast-forward application.properties | 2 +- web-app/WEB-INF/applicationContext.xml | 3 ++- web-app/WEB-INF/sitemesh.xml | 4 +++- 3 files changed, 6 insertions(+), 3 deletions(-) it does the same thing with extra steps and an additional 
 merge commit
54. Interactive rebase
 to squash your commits be sure that we only deal with the local commits 6 ➜ git:(feature-1185-add-commenting) git rebase -i origin/development pick 4559eba updated application version pick d1706ae added comments for applicationContext.xml pick d3c2734 added comments for sitemesh.xml git will display an editor with a list of the commits to be modified pick 4559eba updated application version squash d1706ae added comments for applicationContext.xml squash d3c2734 added comments for sitemesh.xml Now we need to tell git what to do. keep the first one as it is and change the others as “squash” updated application version, added comments to applicationContext.xml and siteMesh.xml files Git squashes the commits together to one commit and opens a new editor to enter commit message Now the last 3 commits are squashed into one commit with a special commit message
55. merge your changes
 with development branch It’s time to merge the completed work 7 ➜ git:(feature-1185-add-commenting) git checkout development Switched to branch 'development' Your branch is behind 'origin/development' by 3 commits, and can be fast-forwarded. (use "git pull" to update your local branch) ➜ git:(development) git pull Updating c827c84..7761c9c Fast-forward application.properties | 2 +- grails-app/controllers/org/example/ShelfController.groovy | 6 ++++++ grails-app/domain/org/example/Shelf.groovy | 7 +++++++ test/unit/org/example/ShelfControllerTests.groovy | 17 +++++++++++++++++ test/unit/org/example/ShelfTests.groovy | 17 +++++++++++++++++ 5 files changed, 48 insertions(+), 1 deletion(-) create mode 100644 grails-app/controllers/org/example/ShelfController.groovy create mode 100644 grails-app/domain/org/example/Shelf.groovy create mode 100644 test/unit/org/example/ShelfControllerTests.groovy create mode 100644 test/unit/org/example/ShelfTests.groovy ➜ git:(development) git merge feature-1185-add-commenting Updating 7761c9c..d55ee12 Fast-forward application.properties | 2 +- web-app/WEB-INF/applicationContext.xml | 3 ++- web-app/WEB-INF/sitemesh.xml | 4 +++- 3 files changed, 6 insertions(+), 3 deletions(-) someone pushed before we merge, dammit!
56. push your changes to the upstream 8 ➜ git:(feature-1185-add-commenting) git push origin development Counting objects: 13, done. Delta compression using up to 4 threads. Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 759 bytes | 0 bytes/s, done. Total 7 (delta 4), reused 0 (delta 0) To UberProject.git 7761c9c..d55ee12 development -> development
57. tıps for efficient usage of git and git branching model
58. Learn git Command Line by heart, stop using GUI GUI is extremely messy when you need to do stuff like merging and branching. 1
59. Only few people should be authorised for merging development branch to master branch for doing a the last review during merge by technical leads 2
60. check-in others code at least once a day It’s better to check-in whenever possible 3
61. ensure that all tests are passing
 before pushing to upstream 4
62. never rebase shared commits 5 rebase only the branch where no one have checked in yet
63. do not push half-baked, untested, incomplete, 
 not-compiling, to-be-fixed, not-ready-to-deploy code to git push to remote whenever the code is ready to deploy 6
64. Have meaningful distinguishing comments for commits include bug or story ids too 7
65. Never use                    flag to git commit and Follow Commit message best practices 8 • First line is 50 characters or less. That is summary. • Then a blank line • Remaining text should be wrapped at 72 characters. That is detailed description                         -­‐m  <message>
66. Squash commits of your completed story into one before pushing to upstream we are not interested in internals of stories 9
67. Squash commits of bug fix into one and exactly one commit that completely represents that bug fix Half of bugfix is useless 10
68. Never bundle logically different components in the same commit think about rolling back too 11
69. Commit often, perfect later, publish once 12
70. Use .gitıgnore in order not to send irrelevant files 13 never push irrelevant binaries, packages, compiled files, temp files, IDE or OS related files
71. Always review code before Committing it 14 check what you sent to staging area
72. Clean up unused and out-of-date suPpoRTing branches and never delete unmerged remote branches 15
73. do not reset without stashing or committing & tagging 16 no one wants to lose code, uh?
75. references “A successful git branching model” “A git workflow for agile teams” http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html “merge or rebase” http://blog.sourcetreeapp.com/2012/08/21/merge-or-rebase/ “git pull --rebase by default” http://d.strelau.net/post/47338904/git-pull-rebase-by-default “a rebase workflow for git” http://www.randyfay.com/node/91 “A DEEP DIVE INTO THE MYSTERIES OF REVISION CONTROL” http://blog.experimentalworks.net/2009/03/merge-vs-rebase-a-deep-dive-into-the-mysteries-of-revision-control http://nvie.com/posts/a-successful-git-branching-model and good to reads
76. references “GIT BEST Practices” http://sethrobertson.github.io/GitBestPractices “GIT BEST Practices: Workflow Guidelines” http://www.lullabot.com/blog/article/git-best-practices-workflow-guidelines “5 useful tips for a better commit message” http://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message “Proper git commit messages and elegant git history” http://ablogaboutcode.com/2011/03/23/proper-git-commit-messages-and-an-elegant-git-history “branch per feature” http://dymitruk.com/blog/2012/02/05/branch-per-feature/ and good to reads http://www.flickr.com/photos/ableman/1209643278 http://www.flickr.com/photos/ibnhusin/3883416540 http://www.flickr.com/photos/mylor/314975954/ http://www.ccjdigital.com/files/2010/08/highways.jpg http://www.flickr.com/photos/librariesrock/4275765000 http://15pictures.com/wp-content/gallery/15-pictures-adriana-lima/adriana-lima-1.jpg ımages
77. Lemİ orhan ergİn @lemiorhan @lemiorhan agilistanbul.com @lemiorhan Principal Software Engineer @ Sony Founder & Author @ agilistanbul.com lemiorhanergin.com lemiorhan@agilistanbul.com