Slawomir effective git for distributed teams

561 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
561
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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?

×