Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Eclipse, Git und Gerrit

7.121 Aufrufe

Veröffentlicht am

Slides for the gearconf (mainly in German)

Veröffentlicht in: Technologie, Sport
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Eclipse, Git und Gerrit

  1. 1.  EffizienteEntwicklungsprozessemit Eclipse, Git und Gerrit<br />http://eclipse.org/egit<br />+<br />=<br />Stefan Lay (SAP)<br />stefan.lay@sap.com<br />Twitter: @stefanlay<br />
  2. 2. Agenda<br />Git – einverteiltesVersionierungssystem<br />Gitbei Eclipse und innerhalbeinesUnternehmens<br />Code Review mitGerrit<br />Demo: LebenszykluseinerÄnderung<br />Q & A<br />  <br />Effiziente Entwicklungsprozesse mit Eclipse, Git und Gerrit | © 2010 by Stefan Lay, SAP AG<br />
  3. 3. Die Hauptdarsteller<br />GitisteinverteiltesVersionierungssystem<br />EGitisteinEclipse Team Provider fürGit<br />http://www.eclipse.org/egit/<br />JGitisteineleichtgewichtige Java-BibliothekfürGit<br />http://www.eclipse.org/jgit/<br />Gerritistein Code-Review-System, basierend auf JGit <br />http://code.google.com/p/gerrit/<br />Effiziente Entwicklungsprozesse mit Eclipse, Git und Gerrit | © 2010 by Stefan Lay, SAP AG<br />
  4. 4. Geschichte von Git, JGit und EGit<br />2005    LinusTorvaldsinitiiertGit<br />2006    Shawn Pearce initiiert JGit<br />2009    Eclipse entscheidetsichfürGit JGit/EGit ziehen um nach eclipse.org SAP beteiligtsich <br />3/2010 JGit/EGit Release 0.7 (erstes Release bei Eclipse)              <br />            Diff/Merge Algorithms, Automatic IP Logs<br /> <br />6/2010Release 0.8 (Helios)<br />            GitRepositories View, Tagging<br />9/2010Release 0.9 (Helios SR1)<br /> Merge, Synchronize View, .gitignore<br />Effiziente Entwicklungsprozesse mit Eclipse, Git und Gerrit | © 2010 by Stefan Lay, SAP AG<br />
  5. 5. 5<br />Git vs. CVS/SVN<br /><ul><li>Zentralisiert
  6. 6. --
  7. 7. --
  8. 8. Langsam
  9. 9. Patches veralten
  10. 10. Merge ist problematisch
  11. 11. Verteilt
  12. 12. Historie lokal
  13. 13. Offline-Arbeit mit Versionierung
  14. 14. Schnell
  15. 15. Einfaches Rebase
  16. 16. Sehr gute Mergeunterstützung -> lokale Feature-Branches</li></ul>Understanding and Using Git at Eclipse | © 2010 by C. Aniszczyk, S. Pearce, R. Rosenberg and M. Sohn <br />
  17. 17. Eclipse - Rollen<br />Committer<br />Gewählt in einemformalenProzess<br />KanneigeneÄnderungenohne Review committen<br />Contributor<br />KleineÄnderungen<br /> von Committerngereviewt<br />GrößereÄnderungen<br />zusätzlichformales IP review in speziellemgeschütztenBugzilla<br />Review Tool<br />Patches werden an Bugzillaangehängt<br />Kommentare in Bugzilla<br />Effiziente Entwicklungsprozesse mit Eclipse, Git und Gerrit | © 2010 by Stefan Lay, SAP AG<br />
  18. 18. Code Review in Bugzilla<br />Code Review | © 2010 by M. Sohn<br />
  19. 19. Git @ Eclipse<br />EGit/Jgit-Entwicklung: http://egit.eclipse.org<br />http://git.eclipse.org/hostetlive Eclipse Git Repositories<br />Virgo, Mylyn Review, ScalaModules, SWTBot …<br />http://dev.eclipse.org/git/index.html git mirrors für CVS<br /> Read-only Kopien, up-to-date<br />Clonenmitgit:// oder http://<br />“Git is the future SCM of Eclipse (Chris Aniszczyk)”<br />Effiziente Entwicklungsprozesse mit Eclipse, Git und Gerrit | © 2010 by Stefan Lay, SAP AG<br />
  20. 20. Git innerhalb eines Unternehmens?<br />Git wurde für die Entwicklung des Linux Kernels konzipiert<br />Verteilte Entwicklung bringt Vorteile für Contributors in Open-Source-Projekten<br />Comitter / contributor model auch innerhalb eines Unternehmens -> für re-use-Komponenten<br />Produktivität durch lokale Feature branches<br />Gitand Gerrit ermöglichen einen (Peer) Code reviewworkflow<br />
  21. 21. Peer Code Review<br />Guido van Rossum, Google [1]<br />When one developer writes code, another developer is asked to review that code<br />A careful line-by-line critique <br />Happens in a non-threatening context <br />Goal is cooperation, not fault-finding <br />Often an integral part of coding process<br />Debugging someone else's broken code<br />– Involuntary code review: Not so good; emotions may flare<br />[1] http://code.google.com/p/rietveld/downloads/detail?name=Mondrian2006.pdf<br />Code Review | © 2010 by M. Sohn<br />
  22. 22. Code Review – Benefits<br />Guido van Rossum, Google [1]<br />Four eyes catch more bugs<br /><ul><li>Catch bugs early to save hours of debugging</li></ul>Enforce coding standards<br /><ul><li>Keep overall readability & code quality high</li></ul>Mentoring of new developers <br /><ul><li>Learn from mistakes without breaking stuff</li></ul>Establish trust relationships <br /><ul><li>Prepare for more delegation</li></ul>Good alternative to pair programming<br /><ul><li>asynchronous and across locations</li></ul>[1] http://code.google.com/p/rietveld/downloads/detail?name=Mondrian2006.pdf<br />Code Review | © 2010 by M. Sohn<br />
  23. 23. Gerrit Code Review<br />Gerritista ein auf JGit basierendes Code-Review-System<br /><ul><li>http://code.google.com/p/gerrit/
  24. 24. DientauchalsgitServer
  25. 25. FügtZugriffskontrolleund Workflow hinzu
  26. 26. Benutzt von
  27. 27. Androidhttps://review.source.android.com/
  28. 28. JGit, EGithttp://egit.eclipse.org/r/
  29. 29. Google, SAP, …
  30. 30. Eclipse hat großesInteresse (Bug 283749)…</li></ul>Code Review | © 2010 by M. Sohn<br />
  31. 31. Ein Branch per Feature<br />Master branch enthältnurakzeptierteÄnderungen<br />Master verbessertsichmitjedem Commit<br />JederFeature branch basiert auf demMaster branch<br />StabilerStartpunkt<br />Neueste Commits in master könnenleicht in die Änderungintegriertwerden<br />Git rebase isthiersehrhilfreich<br />EineÄnderungkannleichtverworfenwerden<br />KeineandereÄnderunghängt von ihrab<br />Code Review | © 2010 by M. Sohn<br />
  32. 32. Gerrit - Workflow<br />Code Review | © 2010 by M. Sohn<br />
  33. 33. Gerrit<br />http://egit.eclipse.org/r/ - change,825<br />Code Review | © 2010 by M. Sohn<br />
  34. 34. Gerrit – LebenszykluseinerÄnderung<br /><ul><li>lokaler Feature Branch
  35. 35. commit
  36. 36. push auf Gerrit
  37. 37. review
  38. 38. automatischeVerifizierung</li></ul>topic<br />master<br />1<br />a<br />Code Review | © 2010 by M. Sohn<br />
  39. 39. Gerrit – LebenszykluseinerÄnderung<br /><ul><li>lokaler Feature Branch
  40. 40. commit
  41. 41. push auf Gerrit
  42. 42. review
  43. 43. automatische Verifizierung</li></ul>topic<br />master<br />1<br />a<br />master<br />topic<br /><ul><li>Verbesserung auf Basis des Reviews
  44. 44. pushenneuer Patch Sets</li></ul>c<br />3<br />b<br />2<br />a<br />1<br />Code Review | © 2010 by M. Sohn<br />
  45. 45. Gerrit – LebenszykluseinerÄnderung<br /><ul><li>lokaler Feature Branch
  46. 46. commit
  47. 47. push auf Gerrit
  48. 48. review
  49. 49. automatischeVerifizierung</li></ul>master<br />topic<br />master<br />d<br />topic<br />1<br />a<br />c<br />3<br />b<br />2<br />master<br />topic<br /><ul><li>Verbesserung auf Basis des Reviews
  50. 50. pushenneuer Patch Sets</li></ul>a<br />c<br />1<br />3<br />b<br /><ul><li> Submit kannzuserverseitigem merge führen
  51. 51. Alternative: Lokalesmergen/ rebasenvordem push</li></ul>2<br />a<br />1<br />Code Review | © 2010 by M. Sohn<br />
  52. 52. Code Review – UnsereErfahrungen<br />AlleÄnderungenwerdengereviewt!<br />Ein Review kanndauern(1 Tag … Wochen) <br />Codeautoren müssen auf den Review warten<br />Einparalleler Workflow istnötig<br />JedesTeammitgliedsolltesichbeteiligen<br />Git & Gerritsindaußerordentlichhilfreich<br />Code Review | © 2010 by M. Sohn<br />
  53. 53. Code Review – Tipps<br />KleineÄnderungen<br />EineÄnderungsollteatomarsein<br />EineÄnderungsollteweder Build noch Tests brechen<br />GrößereÄnderungensollten in eineSerie von kleinerenunterteiltwerden (patch series)<br />- Die letzteÄnderungschaltet das Feature ein<br />Die Commit message sollte das Warumerläutern<br />- Das Wassollteausdem Code klarhervorgehen<br />Code Review | © 2010 by M. Sohn<br />
  54. 54. No Free Lunch -- DEMO<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br />The best way to learn Git is to use Git<br />Understanding and Using Git at Eclipse | © 2010 by C. Aniszczyk, S. Pearce, R. Rosenberg and M. Sohn <br />
  55. 55. Zusammenfassung<br />DVCS wiez.B. Gitsindleistungsstark<br />Gitunterstützt Branches und Merging hervorragend<br /> <br />Gitistschnell und skaliert<br /> <br />Gerritermöglichteinen Review workflow<br />Gitund Gerriteignensichfür den EinsatzimUnternehmen<br />Understanding and Using Git at Eclipse | © 2010 by C. Aniszczyk, S. Pearce, R. Rosenberg and M. Sohn <br />
  56. 56. Resources<br />Ask questions on the EGit forum or egit-dev/jgit-dev lists<br />http://git-scm.com/documentation is your friend<br />If you want comedy, watch Linus' talk at Google<br />    http://www.youtube.com/watch?v=4XpnKHJAok8<br />Read the Pro Git book - http://progit.org/book/<br />Understanding and Using Git at Eclipse | © 2010 by C. Aniszczyk, S. Pearce, R. Rosenberg and M. Sohn <br />
  57. 57. Features EGit 0.8<br />Supported<br />Partially supported<br />Not yet supported<br />* planned for 0.9<br /><ul><li>git init / git clone
  58. 58. git add
  59. 59. git status
  60. 60. git commit
  61. 61. git diff
  62. 62. git fetch
  63. 63. git log
  64. 64. git merge *
  65. 65. git rebase
  66. 66. git remote
  67. 67. git pull
  68. 68. git push
  69. 69. git stash *
  70. 70. git branch
  71. 71. git tag
  72. 72. git checkout
  73. 73. git config
  74. 74. git format-patch
  75. 75. git mv / git rm
  76. 76. git reset
  77. 77. .gitignore *
  78. 78. synchronizeview *</li></ul>24<br />
  79. 79. Eclipse – Review Process<br />Contributors<br /><ul><li>create patch using CVS, SVN, Git
  80. 80. attach patch to bug in Bugzilla</li></ul>Committers<br /><ul><li>do code and IP review
  81. 81. comment, vote in Bugzilla
  82. 82. create CQ for changes needing IP review
  83. 83. commit accepted changes</li></ul>IP Team<br /><ul><li>does IP review bigger changes from contributors</li></ul>Code Review | © 2010 by M. Sohn<br />
  84. 84. Gerrit- Workflow <br />Every change is reviewed<br />- Authors can invite reviewers<br /> - Complex changes reviewed by many<br />Look at the change<br />- Comment on how to improve it<br />- Discuss in context of the change<br />Download the change<br />- test it<br />- improve it<br />Discussion usually leads to new improved change<br />Code Review | © 2010 by M. Sohn<br />
  85. 85. Code Review<br />dailyworkwithcodereview<br />improvesquality<br />helpslearningandavoidingsilos<br />reviewtakes time -> parallel workflow -> githelps a lothere<br />peercodereviewandautomatedverification on isolatedchange -> voting -> improvechangebased on comments -> submittomaster -> centralbuildandtest<br />

×