Git workflows á la-carte, Presenation at jdays2013 www.jdays.se by Nicola Paolucci
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Git workflows á la-carte, Presenation at jdays2013 www.jdays.se by Nicola Paolucci

on

  • 401 views

Git Workflows A-la-carte, Presenation at jdays2013 www.jdays.se by Nicola Paolucci

Git Workflows A-la-carte, Presenation at jdays2013 www.jdays.se by Nicola Paolucci

Statistics

Views

Total Views
401
Views on SlideShare
401
Embed Views
0

Actions

Likes
1
Downloads
12
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Git workflows á la-carte, Presenation at jdays2013 www.jdays.se by Nicola Paolucci Presentation Transcript

  • 1. Workflows á-la-carte
  • 2. Nicola Paolucci Developer Advocate / Git Evangelist I come out nice in pictures, I know :-). durdn.com @durdn
  • 3. You heard has Cheap local branching Full local history 10x the speed of svn Staging area Speed Huge community Feature based workflow prominent in Open Source cryptographic integrity Distributed
  • 4. ground breaking paradigm is ground breaking
  • 5. Workflow building blocks fork cheap branching rebase powerful merging distributed clone
  • 6. Can we do a fast Can we fix a bug for the upcoming RELEASE HOTFIXrelease? for the current ? Can we BUILD the current code ? Is the code for that FEATURE complete? Has everybody REVIEWED ? the code for this feature
  • 7. What we’ll cover: 1 Branching models 2 Practices & Decisions 3 Tooling & Automation 4 Continuous Integration
  • 8. 1 Which branching model?
  • 9. Two common Branching Models 1 Continuous Delivery 2 Product Releases
  • 10. 1.1 for Continuous Delivery
  • 11. staging promoted from staging, can receive hotfixes Time feature master/ production master is in production PR staging is the next version new features off staging with branch names like: Hotfix username/ISSUE-KEY-summary
  • 12. 1.2 for Product Releases
  • 13. PRJ-123-description PRJ-123-bug-description Time feature bugfix branches branch master 1 One Central Repository 2 One Branch per Feature 3 One Branch per Bugfix
  • 14. master Long running 2.2 PRJ-345-bug-description Time bugfix release branch 4 Release Branches 5 master is alpha / RC
  • 15. Automatic merges for the win!
  • 16. Automatic MERGES! release branch release branch 2.1 2.2 PRJ-345-bug-description Time bugfix master
  • 17. Placeholder for changes you DON’T want to merge!
  • 18. release branch release branch 2.1 2.2 2.2.1 2.1.4 2.1.5-SNAPSHOT What can we do here? We don’t want to merge the 2.1.x version!
  • 19. git merge --strategy= ours
  • 20. stable branch stable branch 2.1 2.2 2.2.1 2.1.4 2.1.5-SNAPSHOT $> git checkout stable-2.2 $> git merge -s ours stable-2.1 merge commit, content discarded
  • 21. Deep breath, it’s really simple
  • 22. The secret sauce The merge protocol
  • 23. The secret sauce The merge protocol When a branch is: Change flows from 
 branch to baseline: Change flows from baseline to branch: More stable than its baseline Continuously Never When code complete Continuously Release branch Less stable than its baseline Feature branches Credit: Laura Wingerd - The Flow of change
  • 24. The secret sauce The merge protocol Release Branch Never Merge merge! continuously Master Backport single changes using git cherry-pick
  • 25. turbo boost! 2 Practices & Decisions
  • 26. What is a Pull Request?
  • 27. Pull Request I have some code here! Hey I have some code I want to merge here, take a look? Low friction collaboration Can I merge it here?
  • 28. Merge vs Rebase Does a debate even exist? REBASE MERGE
  • 29. What is a Rebase? Merge commit feature master feature master
  • 30. Merge as team policy with no fast-forwards 1 Traceability 2 At a cost: readability 3 bisect debugging is harder
  • 31. Rebase as team policy [1] 1 History flat and clean 2 Delicate with Pull Requests 3 Dangerous for unexperienced
  • 32. Rebase as team policy [2] 4 Re-resolve similar conflicts 5 Requires often a force push 6 Loses context for feature
  • 33. Rebase as a local cleanup git rebase --interactive 1 Do it 2 Do it 3 Do it!!!!!!
  • 34. Recommendation? 1 If team unfamiliar, don’t rebase 2 Encourage rebase as cleanup and proper ecology
  • 35. Recommendation? Explicit merges into the mainline 3 Don’t fear the Merge! Use it! git log --first-parent After review! 4 May rebase feature branches To update the feature branch 5 Work with the tool! Trying to strive for a linearized history is less useful than you think
  • 36. Single Repository vs Remote Forks
  • 37. With Forks Every one has their remote repository Full remote copy, each has one Integrator, Gatekeeper, Tech Lead, etc.
  • 38. Pros of a Single Repo All feature branches available 1 Complete visibility 2 No per Dev remotes required 3 KISS
  • 39. Forks Are Great too BTW
  • 40. FORKING IN THE ENTERPRISE
  • 41. FORKING IN 5 Reasons for... ENTERPRISE REASON 1 Great for customizing libraries and still get bug fixes
  • 42. FORKING IN ENTERPRISE REASON 2 Great for innovation spikes and maybe add it later
  • 43. FORKING IN but still be open for changes REASON 3 Protecting your components ENTERPRISE
  • 44. FORKING IN ENTERPRISE REASON 4 Reduce the noise and keep the overview for huge projects
  • 45. FORKING IN ENTERPRISE REASON 5 Interaction with Contractors & Interns protect your sources
  • 46. 3 Tooling & Automation
  • 47. Hooks
  • 48. “ Hooks are little scripts you can place in the `$GIT_DIR/hooks` directory to trigger action at certain points. – githooks Documentation ”
  • 49. Pre Post
  • 50. Local Remote
  • 51. Local pre-/post-applypatch pre-/post-commit Remote pre-receive update pre-rebase post-receive post-checkout post-update post-merge pre-push
  • 52. Code Quality via pre-commit hooks
  • 53. .git/hooks/pre-commit!
  • 54. git add -u! git commit -m "TEST checkstyle"!
  • 55. Starting audit...! ! /Users/user/[...]/com/atlassian/stash/ web/projects/ProjectController.java: 161:12: 'for' is not followed by whitespace.! ! Audit done.! Commit aborted.
  • 56. Branch from green builds
  • 57. .git/hooks/post-checkout
  • 58. $ git checkout master! master is lookin'good! ! c4f3b4b has 4 green builds.!  ! $ git checkout stable-2.3 ! DANGER! stable-2.3 is busted. e1324fa has 2 red builds.!
  • 59. Get it at: bitly.com/green-builds
  • 60. 4 What happens to CI with ?
  • 61. 1 What happens to CI with git? 2 An explosion of branches 3 Performance degradation of build sys
  • 62. 1 Building everything is expensive 2 Automatically build stable and master 3 Manually trigger feature branch builds
  • 63. In Conclusion: the recipe
  • 64. Conclusions Collaboration Model Branching Model Product ! Centralized ! ! workflow ! ! ! Continuous delivery workflow Practices & Decisions Embrace PR ! ! Merge vs ! ! Rebase ! Single Repo or Forks Automation & CI setup Hooks, hooks everywhere ! ! ! Build ! automatically, ! but leave knobs!
  • 65. Nicola Paolucci THANK YOU FOR YOUR ATTENTION! Should I change the pic? ;-) durdn.com @durdn
  • 66. http://strawpoll.me/774809
  • 67. Atlassian Git Repository Management for Enterprise Teams Free Git Code Hosting for Small Teams Free Git Desktop client for Mac or Windows