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.

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