Branches & Merges are Bears, Oh My!

Branches & Merges are Bears, Oh My!

Branching and merging our code is one of the most fundamental things we do as developers. It's also frequently one of the things that gives us the biggest headaches. It turns out that branching isn't the pain point. It's merging. But poor branching practices can make merging more painful. In this session you will many causes of poor branching and effective ways to make merges less painful. Whether you are using Git, TFS, Subversion, or something else, you will walk away will useful practices that you can start using right away.

008c45c68ff49184796deda5faca4126?s=128

Craig Berntson

May 02, 2016
Tweet

Transcript

  1. BRANCHES AND MERGES ARE BEARS, OH MY! Craig Berntson

  2. EGO STUFF AUTHOR Continuous Integration in .NET Manning Publishing MICROSOFT

    MVP 20+ years, currently for Developer Tools .NET ARCHITECT TECHNICAL SPEAKER 20+ years as international speaker AUTHOR Software Gardening column DNC Magazine COMMUNITY INFLUENCER Grape City / ComponentOne
  3. TODAY’S AGENDA Overview of Version Control Avoid Branching Smart Branching

    Best Practices
  4. OVERVIEW OF VERSION CONTROL

  5. VCS SCC

  6. VCS GENERATIONS First • No network • One file at

    a time • File locks • Sneaker-net • RCS, SCSS Second • Centralized • Multi-file • Merge before commit • CVS, SVC, VSS, TFS Third • Distributed • Change sets • Commit before merge • Git, Mercurial
  7. VCS TYPES Centralized • CVS • Subversion • TFS Distributed

    • Git • Mercurial • Telelogic Stream- based • ClearCase • AccuRev
  8. CENTRALIZED VCS Repo Files (read-only) Developer

  9. DISTRIBUTED VCS Origin Remote (exact duplicate of origin) Developer

  10. WHY DO TEAMS BRANCH Physical • Files • Components •

    Subsystems Functional • Features • Logical changes • Bug fixes • Enhancements • Patches • Releases
  11. WHY DO TEAMS BRANCH Environmental • Build and runtime environment

    • Compilers • Windowing systems • Libraries • Hardware • Operating systems Organizational • Activities • Tasks • Subprojects • Roles • Groups
  12. WHY DO TEAMS BRANCH Procedural • Team’s work behavior •

    Policies • Processes • States
  13. VCS GOALS Work simultaneously Track changes Changes don’t conflict Check

    in every version of everything Extract source at any point in time
  14. COMMON SCENARIO

  15. WHY IS THIS BAD? Delayed release Fewer features Lower quality

    Complex merge at release Large changes merged Poorly planned branching
  16. CONTINUOUS DELIVERY PIPELINE Automated deployment Manual testing Automated testing Continuous

    Integration • Check into VCS often • Every build is a potential release candidate • Branching is an anti-pattern • Lean: Branch is waste
  17. WHY CARE ABOUT THIS • Good version control is key

    to the deployment pipeline • Bad version control is a common barrier to fast, low-risk releases
  18. HOW TO FIX THIS • Avoid branching • Smart branching

  19. AVOID BRANCHING

  20. DEVELOP ON TRUNK/MASTER Hide new functionality Incremental changes Abstraction Components

  21. DEVELOP ON TRUNK/MASTER

  22. HIDE FUNCTIONALITY (FEATURE SWITCHES) • Put in new features but

    make them inaccessible to users • Turn on/off through configuration • Planning and delivery become easier
  23. INCREMENTAL CHANGES • When making large changes, it is tempting

    to branch so developers work faster • Reality is, the bigger the perceived reason to branch, the more you shouldn’t branch • Break-down major changes into very small parts and implement each on the trunk
  24. ABSTRACTION 1. Create an abstraction layer over code that needs

    to be changed 2. Refactor code to use abstraction 3. Create the new implementation 4. Update abstraction to use new code 5. Remove old code 6. Remove abstraction layer if not needed
  25. COMPONENTS A component is reusuable, replaceable with something else that

    implements the same API, independently deployable, and encapsulates some coherent set of behaviors and responsibilities of the system - Continuous Deployment
  26. COMPONENTS • Part of codebase needs to be deployed separately

    • Move from monolithic codebase to core and plugins • Provide an interface to another systems • Compile and link cycle are too long • Takes too long to open project in IDE • Codebase is too large for a single team
  27. ISSUES WITH COMPONENTS • Components everywhere • God components •

    Teams are responsible for individual components • Increased dependency management
  28. COMPONENTS

  29. SMART BRANCHING

  30. WHEN TO USE BRANCHING • Release a new version •

    Spike out new feature or major refactoring • Large changes that can’t be done with other methods
  31. DEVELOP ON TRUNK/MASTER Branch for release Branch by feature Branch

    by team
  32. BRANCH FOR RELEASE • Develop on trunk • Branch when

    code is feature complete • Critical defects are committed on branches, then merged immediately • Tag the branch when released • Don’t create another branch until after release
  33. BRANCH FOR RELEASE

  34. BRANCH FOR RELEASE

  35. BRANCH BY FEATURE • Each user story is a branch

    • Number of branches == number of stories • After a story passes QA, merge into trunk • Trunk changes merge into branches daily • Branches live a few days or less • Refactorings are merged immediately
  36. BRANCH BY FEATURE

  37. BRANCH BY TEAM • Teams must be small and independent

    • Merge branches into trunk when stable then immediately into other branches • Similar to Branch by Feature but merges more often • CI Problem: Unit of work is scoped to branch, not a single change.
  38. BRANCH BY TEAM

  39. BEST PRACTICES

  40. BEST PRACTICES • Compare before you commit • Explain commits

    (comments) • Read merge comments from other devs • Keep repositories small • Group commits logically • Only store what’s manually created
  41. BEST PRACTICES • Don’t break the tree • Use tags

    • Don’t obliterate • Don’t comment out old code • Don’t lock files • Build and test before every commit • Build and test after every merge
  42. RECAP

  43. RECAP • Version Control Overview • History • Types •

    Why branch • Centralized • Distributed
  44. RECAP • Avoid Branching (Work on trunk) • Hide new

    functionality • Incremental changes • Abstraction • Components
  45. RECAP • Smart Branching • Branch for release • Branch

    by feature • Branch by team
  46. CONTACT / QUESTIONS craig@craigberntson.com @craigber www.craigberntson.com blogs.msmvps.com/craigber www.dotnetcurry.com www.speakerdeck.com/craigber speakerrate.com/craigber

  47. None