Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Slawomir effective git for distributed teams

656 views

Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

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?

×