Git and Git Workflow Models as Catalysts of Software Development

11,326 views

Published on

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.

Published in: Technology, Business
2 Comments
80 Likes
Statistics
Notes
No Downloads
Views
Total views
11,326
On SlideShare
0
From Embeds
0
Number of Embeds
891
Actions
Shares
0
Downloads
722
Comments
2
Likes
80
Embeds 0
No embeds

No notes for slide

Git and Git Workflow Models as Catalysts of Software Development

  1. 1. GIT & GIT workflow MODELs AS CATALYSTS OF SOFTWARE DEVELOPMENT @lemiorhan Lemİ Orhan ERGİN lemiorhanergin.com @lemiorhan
  2. 2. Lemİ Orhan Ergİn CSM, PSM1 2013 Principal Software Engineer at Sony 2001 has worked in Tüsside, BYM, GittiGidiyor/eBay and Sony as lead developer, technical leader, technical coordinator and scrum master 2009 2 2005 using Git, but not an expert agile 0.5M experienced in agile transformation and building agile culture in teams & organisations organisational level SVN to GIT migration projects experienced so far doing code reviews as a daily habit total number of views of his presentations
  3. 3. I love git
  4. 4. I love git because… I used SVN for a while Local branching is cheap Everything is local Distributed Ruby on Rails with full history and branches weight 13Mb.
 Small and efficient It weights 115Mb in SVN Any workflow Each object is compressed by zlib and transferred over wire Lightening Fast one by one Huge community More than 3M people˝ More than 5M repositories˝ GitHub… Thanks God! Raised $100 million on July'12
  5. 5. git data model is hot It is a directed acyclic graph Objects (blob, tree, commit, tag) are immutable References (branch, remote) always change
  6. 6. Stop comparing SVN with GIT It is not a magical version of SVN. Try to understand what it's actually doing.
  7. 7. “ It's a stupid content tracker. 
 It tracks files and folders. 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. LINUS TOVALDS ”
  8. 8. git changed the way we think of merging branching workflows
  9. 9. git is a tool for designing vcs workflows
  10. 10. main branches supporting branches Feature development release development hot fixes in production git workflow model
  11. 11. main branches main branches are permanent branches which are created at the very beginning and n ever d elete d!
  12. 12. main branches OPTıONAL development It reflects the latest delivered development changes for the next release Automatic nightly builds test & QA STAGING & UAT MASTER Production
  13. 13. main branches OPTıONAL development test & QA It reflects the code which is deployed to test/qa environment for testing Automatic nightly builds Automatically deployed to test/qa servers every night STAGING & UAT MASTER Production
  14. 14. main branches OPTıONAL development test & QA STAGING & UAT It reflects the code which is deployed to staging/uat environment for testing Automatic nightly builds Automatically deployed to staging servers every night Automatically deployed to test/qa servers every night MASTER Production
  15. 15. main branches OPTıONAL development test & QA STAGING & UAT MASTER Production It reflects the code which is deployed to production Automatic nightly builds Automatically deployed to staging servers every night Automatically deployed to test/qa servers every night Automatically deployed to production servers on demand
  16. 16. supporting branches feature branches HOTFIX branches release branches These have limited life time and will be removed eventually
  17. 17. supporting branches feature branches HOTFIX branches release branches These have specific purpose and strict rules for originating and target branches
  18. 18. Feature development All feature branches should be created from The development branch the n ext r eleas e bra nch
  19. 19. Feature development take a new feature branch regardless of the feature size you ca comm n fix v in dev on issue ery mino elopm s direc r like f ent b tly ixing ranch typos ,
  20. 20. Feature development Ne Feature 1 Feature 2 2 Feature 2 is completed and ready for the next release Feature 3 xt development Rel ea se
  21. 21. Ne Feature development Feature 1 Feature 1 is being developed Feature 2 2 1 Feature 3 xt development Rel ea se
  22. 22. Feature development Ne Feature 1 Feature 2 Feature 3 xt development Rel ea se 2 1 D Feature 2 is completed and merged back to master
  23. 23. Ne Feature development Feature 1 Feature 1 gets the commits in Feature 2 Feature 2 Feature 3 development Rel ea se 2 1 D 1 xt
  24. 24. Ne Feature development Feature 1 Pulls all the commits from other features and resolve conflicts Feature 2 Feature 3 development Rel ea se 2 1 D 1 1 xt D
  25. 25. Feature development Ne Feature 1 Feature 2 Feature 3 xt development Rel ea se 2 1 D 1 D 1 3 Feature 3 is created from development. It has commits of Feature 2
  26. 26. Feature development Ne Feature 1 Feature 2 Feature 3 xt development Rel ea se 2 1 D 1 D 1 3 D Feature 1 is completed and merged back to master
  27. 27. Feature development Ne Feature 1 Feature 2 Feature 3 development Rel ea se 2 1 D 1 D 1 3 D 3 Feature 3 gets the commits of Feature 1 xt
  28. 28. Feature development Ne Feature 1 Feature 2 Feature 3 development Rel ea se 2 1 D 1 D 1 3 D 3 3 Feature 3 pull updates frequently xt D
  29. 29. Feature development Ne Feature 1 Feature 2 Feature 3 xt development Rel ea se 2 1 D 1 D 1 3 D 3 3 D D Typo is fixed directly in development branch
  30. 30. Feature development Ne Feature 1 Feature 2 Feature 3 development Rel ea se 2 1 D 1 D 1 3 D 3 Feature 3 pulls commit about fixing the typo 3 3 xt D D
  31. 31. Feature development Ne Feature 1 Feature 2 Feature 3 xt development Rel ea se 2 1 D 1 D 1 3 D 3 3 D D 3 D Feature 3 is completed and merged back to master. It has commits of all 3 features now.
  32. 32. release development Release branch is created when all features are ready for the next release some featu times w re fre e call eze it as
  33. 33. release development Release branch is deleted when the release completes we w code, ill tag t branc no need he releas to ke ed h.. ep th e
  34. 34. release development el N t ex s ea e R development F D F D Completed features are merged with development release MASTER Production
  35. 35. release development el N t ex s ea e R development F D F D D All features are ready for the next release release MASTER Production
  36. 36. release development el N t ex s ea e R development release MASTER Production F D F D Start a release branch when features are freezed D R
  37. 37. release development el N t ex s ea e R development release MASTER Production F D F D D R Only fixes are allowed R D R Bug fixes are continuously merged back to development brach D
  38. 38. release development el N t ex s ea e R development release MASTER Production F D F D D R R D R D R Release is ready now
  39. 39. release development el N t ex s ea e R development release F D F D D R R D R Latest fixes are merged back to development branch D R D MASTER Production
  40. 40. release development el N t ex s ea e R development release MASTER Production F D F D D R R D R D Merge release branch with master branch
 and get a new tag R D M
  41. 41. hot fixes in production Fix branches are required because every fix should be well tested and verified it me to rol ans, you done i lback w may nee n the hat yo d fix u’ve
  42. 42. hot fixes in production el N t ex s ea e R development Hot-FIX MASTER Production Hot fix is required! A new branch is created from production branch M
  43. 43. hot fixes in production el N t ex s ea e R development Hot-FIX MASTER Production M Fix is developed, tested and verified. Ready to go. H
  44. 44. hot fixes in production el N t ex s ea e R development Hot-FIX MASTER Production M H D Hot fixes are merged back to development branch
  45. 45. hot fixes in production el N t ex s ea e R development Hot-FIX MASTER Production M H Hot fix is merged with production branch and production branch is tagged D M
  46. 46. ALL FLOWS IN THE MODEL This graphic is taken from Vincent Driessen’s article called 
 “a successful git branching model”
  47. 47. feature development
  48. 48. 1 creatE permanent branches If these does not exist ➜ 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  it cre branc ates de v pushe h from m elopme s to r aste nt emot r and e
  49. 49. 2 Pull to update
 local development branch be sure you run tests directly afterwards ➜ 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. 50. 3 create a feature branch
 from development with a name having story id and descriptive title ➜ git:(development)  git checkout -b feature-1185-add-commenting Switched to a new branch 'feature-1185-add-commenting'  ➜ git:(feature-1185-add-commenting)   the t hints itle shou about ld giv what e ’s in it
  51. 51. 4 work in your feature branch commit early and often Be careful! “push early it does not mean and often” ➜ 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(-)
  52. 52. 5 rebase frequently
 to incorporate upstream changes to prevent your branch from diverging significantly ➜  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. 53. 5 rebase frequently
 to incorporate upstream changes to prevent your branch from diverging significantly ➜  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(-)  ing th s me tep 
 e sara s onal th xt iti oes h e add mit t d wit an com i and erge m
  54. 54. 6 Interactive rebase
 to squash your commits be sure that we only deal with the local commits ➜  git:(feature-1185-add-commenting) git rebase -i origin/development git will display an editor with a list of the commits to be modified pick 4559eba updated application version pick d1706ae added comments for applicationContext.xml pick 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” pick 4559eba updated application version squash d1706ae added comments for applicationContext.xml squash d3c2734 added comments for sitemesh.xml Git squashes the commits together to one commit and opens a new editor to enter commit message updated application version, added comments to applicationContext.xml and siteMesh.xml files Now the last 3 commits are squashed into one commit with a special commit message
  55. 55. 7 merge your changes
 with development branch It’s time to merge the completed work ➜  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 some we m one push erge, ed bef damm ore it! ➜  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(-)
  56. 56. 8 push your changes to the upstream ➜  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. 57. tıps forand git branching model efficient usage of git
  58. 58. 1 Learn git Command Line by heart, stop using GUI GUI is to do extrem stuff ely m like m essy w erging hen y and b ou need ranch ing.
  59. 59. 2 Only few people should be authorised for merging development branch to master branch for do durin ing a th g mer e last ge by revie techn w ical le ads
  60. 60. 3 check-in others code at least once a day It’s b when etter to ever c possibheck-in le
  61. 61. 4 ensure that all tests are passing
 before pushing to upstream
  62. 62. 5 never rebase shared commits rebas no one e only th have e bran check ch w ed in here yet
  63. 63. 6 do not push half-baked, untested, incomplete, 
 not-compiling, to-be-fixed, not-ready-to-deploy code to git push code i to remot s read e wh y to d enever eploy the
  64. 64. 7 Have meaningful distinguishing comments for commits includ e bug or sto ry ids too
  65. 65. 8                         Never use -­‐m  <message> flag to git commit and                     Follow Commit message best practices characters or less. That is summary. • First line is 50line • Then a blanktext should be wrapped at 72 characters. • Remaining description That is detailed
  66. 66. 9 Squash commits of your completed story into one before pushing to upstream we ar inter e not int nals o eres f stor ted in ies
  67. 67. 10 Squash commits of bug fix into one and exactly one commit that completely represents that bug fix Half o f bug fix is usele ss
  68. 68. 11 Never bundle logically different components in the same commit think about rolling back too
  69. 69. 12 Commit often, perfect later, publish once
  70. 70. 13 Use .gitıgnore in order not to send irrelevant files never packa push irr IDE or ges, com elevant OS re piled binar lated files, ies, files temp file s,
  71. 71. 14 Always review code before Committing it check stagi what y ng are ou se nt to a
  72. 72. 15 Clean up unused and out-of-date suPpoRTing branches and n remotever del e bra ete un nches merg ed
  73. 73. 16 do not reset without stashing or committing & tagging no one want s to l ose co de, uh ?
  74. 74. references and good to reads “A successful git branching model” http://nvie.com/posts/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
  75. 75. references and good to reads “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/ ımages 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
  76. 76. @lemiorhan @lemiorhan @lemiorhan agilistanbul.com Lemİ orhan ergİn lemiorhan@agilistanbul.com lemiorhanergin.com Principal Software Engineer @ Sony Founder & Author @ agilistanbul.com

×