18
Effective Git for Distributed Teams Slawomir Ginter SPARTEZ

Slawomir effective git for distributed teams

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: Slawomir effective git for distributed teams

Effective Gitfor Distributed Teams

Slawomir GinterSPARTEZ

Page 2: Slawomir effective git for distributed teams

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

Page 3: Slawomir effective git for distributed teams

Who this is about?

• Atlassian JIRA Team

• 64 developers (listed in Release Notes)

Page 4: Slawomir effective git for distributed teams

Who this is about?

• Atlassian JIRA Team

• 64 developers

• 3 major geographies (a few “minor”)

Page 5: Slawomir effective git for distributed teams

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

Page 6: Slawomir effective git for distributed teams

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

Page 7: Slawomir effective git for distributed teams

Who this is about?

• Atlassian JIRA Release Cycle

• Major BTF Feature Releases

• Minor BTF Bug fix Releases

• Continuous (+/-) Hosted deployments

• 2 week Iterations

Page 8: Slawomir effective git for distributed teams

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

Page 9: Slawomir effective git for distributed teams

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?

Page 10: Slawomir effective git for distributed teams

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”

Page 11: Slawomir effective git for distributed teams

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

Page 12: Slawomir effective git for distributed teams

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

Page 13: Slawomir effective git for distributed teams

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

Page 14: Slawomir effective git for distributed teams

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

Page 15: Slawomir effective git for distributed teams

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

Page 16: Slawomir effective git for distributed teams

When Pull Request

• Non-urgent, high risk or impact change

• Incomplete change

• Spike result

• “80% done”

• Solution proposal

• Expecting reject or indefinite postponing

Page 17: Slawomir effective git for distributed teams

Handling feedback

• Acknowledge or Ignore

• Iterative reviews

• Technical Debt

• Explicitly tracked

• Explicitly prioritized

• Often Closed/Won’t-Fix

Page 18: Slawomir effective git for distributed teams

Questions?