Successfully reported this slideshow.
Your SlideShare is downloading. ×

Slawomir effective git for distributed teams

Advertisement

More Related Content

Advertisement

More from Agile Lietuva

Advertisement

Related Books

Free with a 30 day trial from Scribd

See all

Slawomir effective git for distributed teams

  1. 1. Effective Git for Distributed Teams Slawomir Ginter SPARTEZ
  2. 2. Legal Disclaimer • SPARTEZ and Slawomir Ginter are Contractors working for Atlassian • The views and opinions expressed in this presentation are those of the author and not necessarily reflect the views of Atlassian • All trademarks and registered trademarks are the property of their respective owners
  3. 3. Who this is about? • Atlassian JIRA Team • 64 developers (listed in Release Notes)
  4. 4. Who this is about? • Atlassian JIRA Team • • 64 developers 3 major geographies (a few “minor”)
  5. 5. Who this is about? • Atlassian JIRA Team • • • • • 64 developers 3 major geographies 8 hours between each Assigned to Themes in given Release Experts for old or brand new areas
  6. 6. Who this is about? • Atlassian JIRA Application • • 12 years old Core and 150+ components ... and some add-ons • • Behind the Firewall & Hosted Different teams, different rules
  7. 7. Who this is about? • Atlassian JIRA Release Cycle • • • • Major BTF Feature Releases Minor BTF Bug fix Releases Continuous (+/-) Hosted deployments 2 week Iterations
  8. 8. Challenges • When the team grows ... ... beyond collocated / same timezone ... beyond isolated modules ... decentralizing Project an Product Management • You wake up with a full dependency graph
  9. 9. Stepping on each other’s toes • Busy repository • “You broke the build!” ! [rejected] master -> master (non-fast-forward) • What’s new? git log master..origin/master • What differs? git log master...origin/master • Should we rebase?
  10. 10. Stepping on each other’s toes • Busy repository, with branches • merging changes in git is easy ... unless you don’t want them on your branch • Merge responsibility for branches • • • • “Where have my changes gone?!” “Are you done yet?” “Go merge your changes” “Go merge my changes”
  11. 11. Stepping on each other’s toes • Busy repository, with stable branches • Cherry picking = merge conflicts git merge -s ours git log master..origin/master • Feature branches git show-branch --merge-base • • Local staging repository With (automatic) CI Plan Branches
  12. 12. Stepping on each other’s toes • Conflicting changes to the same code • • “Lock” the code if you can Long living development branch - • git gives hope of clean merge Who is the “owner” of the code? - asking permission vs forgiveness
  13. 13. When does code have an “owner”? • Collective Code Ownership principle?! • Cross-product component with dedicated team • Actively developed at the moment • Alien technology, impractical deployment, special testing needed • Code Ownership vs Product Ownership
  14. 14. Consulting vs Approval • Peer Review (Post-commit) • • • • to validate the (emergent) design to seek advice to keep interested parties up to date new libraries, programming techniques • Approval for merging feature branch • Internal Pull Request
  15. 15. When Code Review? • In the same repository • • Branch or single changeset Safe to leave changes in the repository • Change is mature and ready for merge (?) • Expecting approval • Clear who is going to merge and when
  16. 16. When Pull Request • Non-urgent, high risk or impact change • Incomplete change • • • Spike result “80% done” Solution proposal • Expecting reject or indefinite postponing
  17. 17. Handling feedback • Acknowledge or Ignore • Iterative reviews • Technical Debt • • • Explicitly tracked Explicitly prioritized Often Closed/Won’t-Fix
  18. 18. Questions?

×