Upload
agile-lietuva
View
312
Download
3
Embed Size (px)
DESCRIPTION
Citation preview
Effective Gitfor Distributed Teams
Slawomir GinterSPARTEZ
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
Who this is about?
• Atlassian JIRA Team
• 64 developers (listed in Release Notes)
Who this is about?
• Atlassian JIRA Team
• 64 developers
• 3 major geographies (a few “minor”)
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
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
Who this is about?
• Atlassian JIRA Release Cycle
• Major BTF Feature Releases
• Minor BTF Bug fix Releases
• Continuous (+/-) Hosted deployments
• 2 week Iterations
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
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?
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”
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
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
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
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
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
When Pull Request
• Non-urgent, high risk or impact change
• Incomplete change
• Spike result
• “80% done”
• Solution proposal
• Expecting reject or indefinite postponing
Handling feedback
• Acknowledge or Ignore
• Iterative reviews
• Technical Debt
• Explicitly tracked
• Explicitly prioritized
• Often Closed/Won’t-Fix
Questions?