Git effective

77 Aufrufe

Veröffentlicht am

http://www.opitz-consulting.com

git ist ein komplexes Werkzeug im Portfolio eines Entwicklers. Um es effektiv nutzen zu können, benötigt man etwas Einarbeitung und Erfahrung.

In diesem Vortrag stellte unser Java-Experte Thomas Papendieck beim Treffen der Java User Group Frankfurt/M. seine Erfahrungen im Umgang mit git vor und berichtete von Dingen, die seine Projekte voranbrachten und von anderen, die das Team aufhielten.

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

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

Git effective

  1. 1. überraschend mehr Möglichkeiten! © OPITZ CONSULTING 30. August 2017 Informationsklassifikation öffendlich git - effective Java User Group FFM / Nationalbibliothek FFM Thomas Papendieck, Senior–Consultant
  2. 2. Inhalte 1 Branching 2 Commit early, commit often 3 Merge or Rebase, thats the question... © OPITZ CONSULTING 30. August 2017 git - effective 2 / 16
  3. 3. Branching 1.1 Default Branching Model 1.2 Branches explained 1 © OPITZ CONSULTING 30. August 2017 git - effective 3 / 16
  4. 4. Default Branching Model Abbildung: git Workflow by Felix Bruckner (https://blog.oio.de/2014/09/22/git-workflows-teil-2-workflows-meistern/) © OPITZ CONSULTING 30. August 2017 git - effective 4 / 16
  5. 5. master infinite lifetime, dedicated responsible committer, spawns from initial commit. each commit references a shipping event, no direct commits, only merges (--no-ff) from release or fix branch allowed, commits are tagged with version number © OPITZ CONSULTING 30. August 2017 git - effective 5 / 16
  6. 6. develop infinite lifetime, first commit is start of project (initial commit), is always in shippable state. (compiles, all (automated) test pass), every developer can commit a shipping ready feature (but should be done by a build server) © OPITZ CONSULTING 30. August 2017 git - effective 6 / 16
  7. 7. release limited lifetime during feature freeze, spawns from develop, no new features, only fixes, every developer can commit, tag release candidates, build server should merge branch back to develop (at least the ”RC” tags) © OPITZ CONSULTING 30. August 2017 git - effective 7 / 16
  8. 8. hotfix short lifetime, spawns from master (latest commit), every developer can commit, no new features, only (hot) fixes, build server should merge branch back to develop and release (if exists) © OPITZ CONSULTING 30. August 2017 git - effective 8 / 16
  9. 9. feature limited lifetime, spawns from develop, should rebase on / merge new commits in develop, every developer can commit but only assigned developer should, © OPITZ CONSULTING 30. August 2017 git - effective 9 / 16
  10. 10. Commit early, commit often 2 © OPITZ CONSULTING 30. August 2017 git - effective 10 / 16
  11. 11. keep commits small Why should commits be small? improves gits ability to resolve conflicts automatically. improves your ability to resolve conflicts manually. are easier to cherry pick. granularity of documentation (history). changes are easier to find in history. © OPITZ CONSULTING 30. August 2017 git - effective 11 / 16
  12. 12. keep commits clean Commit, when the complete project compiles and all tests pass. commit when: single new behavior completed (TDD-phase 2), single refactoring step completed (TDD-phase 3), merge/rebase conflicts resolved. © OPITZ CONSULTING 30. August 2017 git - effective 12 / 16
  13. 13. Merge or Rebase, thats the question... 3 © OPITZ CONSULTING 30. August 2017 git - effective 13 / 16
  14. 14. merge C0 C1 C2 C3 C4 C5 merge commit benefits: history visualizes parallel work, Conflict resolution only once per merge, configurable automatic conflict resolution (-s recursive -X ours|theirs) drawbacks: complex history graph conflict resolution between final states © OPITZ CONSULTING 30. August 2017 git - effective 14 / 16
  15. 15. rebase C0 C1 C2 C3 C4 C3* C4* benefits: ”clean” history graph (all feature commits consecutive), conflict resolution per commit, less changes at once conflicting changes less likely, automatic resolution more likely, manual resolution easier drawbacks: history not showing ”timeline”, each commit can be conflicting, creates ”orphan” commits © OPITZ CONSULTING 30. August 2017 git - effective 15 / 16
  16. 16. überraschend mehr Möglichkeiten! © OPITZ CONSULTING 30. August 2017 Vielen Dank für die Aufmerksamkeit. Thomas Papendieck Senior–Consultant Norsk–Data–Straße 4 61348 Bad Homburg thomas.papendieck@opitz-consulting.com +49 6172 66260 1523 © OPITZ CONSULTING 30. August 2017 git - effective 16 / 16

×