1. Craig Berntson Chief Software Gardener Mojo Software Worx Branches and Merges are Bears, Oh My!

2. Ego stuff Chief Software Gardener Mojo Software Worx Salt Lake City Organizer, Utah Code Camp Author, “Continuous Integration in.Net” Columnist, “.Net Curry” eMagazine Conference & event speaker 18 time Microsoft MVP INETA Community Speaker ComponentOne Community Influencer 2

3. 3

4. agenda Version control in general Avoid branching Smart branching Best practices 4

5. What do you call it? VCSSCC 5

6. VCS generations First No network One file at a time File locks RCS, SCSS Second Centralized Multi-file Merge before commit CVS, SVN, TFS, VSS Third Distributed Change sets Commit before merge Git, Mercurial 6

7. VCS Types Centralized CVS Subversion TFS Distributed Git Mercurial Telelogic Stream- based ClearCase AccuRev 7

8. Basic goals Work simultaneously Changes don’t conflict Archive every version of everything 8

9. Continuous delivery pipeline Automated Deployment Manual Testing Automated Capacity Testing Automated Acceptance Testing Continuous Integration 9  Check into VCS often  Every build is a potential Release Candidate  Branching is an anti-pattern  Lean: Branch is waste

10. Why care about this? Version control is central to the deployment pipeline Poor version control is a common barrier to fast, low risk releases 10

11. Why teams branch Physical Files Components Subsystems Functional Features Logical changes Bug fixes Enhancements Patches Releases 11

12. Why teams branch Environmental Build and runtime environment Compilers Windowing systems Libraries Hardware Operating systems Organizational Activities Tasks Subprojects Roles Groups 12

13. Why teams branch Procedural Team’s work behavior Policies Processes States 13

14. common scenario 14

15. Common scenario 15

16. Why is this bad? Merge at release Is complex Branching was poorly planned Large changes merged 16 Delayed release Fewer features Lower quality

17. How do you fix this? Avoid branching Smart branching 17

18. Avoid branching Develop on trunk Hide new functionality Incremental changes Branch by abstraction Components 18

19. Hide functionality Put in new features but make them inaccessible to users Turn on/off through configuration Planning and delivery become easier 19

20. Hide functionality 20

21. 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 21

22. Incremental changes 22

23. Branch by abstraction 1.Create an abstraction 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 23

24. Branch by abstraction 24

25. components “A component is reusable, 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 25

26. Why use components Part of codebase needs to be deployed separately Move from monolithic codebase to a core and plugins Provide an interface to another system Compile and link cycle are too long Takes to long to open project in IDE Codebase is too large for a single team 26

27. Issues with components Components everywhere God components Teams are responsible for individual components Increased dependency management 27

28. Branch by abstraction 28

29. avoid branching Develop on trunk Commit code at least daily Changes done in small increments Requires good componentization, incremental changes, feature hiding Gives quick feedback on every change 29

30. When is branching ok? Release a new version of your application Spike out a new feature or refactoring Short-lived branch to make large changes that can’t be done with other methods 30

31. When you need to branch Smart branching Branch for release Branch by feature Branch by team 31

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 32

33. Branch for release 33

34. Branch by feature Each user story is a branch Number of branches = number of stories After story passes QA, merge into trunk Trunk changes merge into branches daily Branches live a few days or less Refactorings are merged immediately 34

35. Branch by feature 35

36. Branch by team Merge branches into trunk when stable then immediately into other branches Teams must be small and independent Similar to Branch by Feature, but merges more often CI Problem: Unit of work is scoped to branch, not a single change 36

37. Branch by team 37

38. Smart branching Branches should be short lived Merge often Requires good project management 38

39. Best practices Compare before you commit Explain commits Read merge comments from other devs Keep repositories small Group commits logically Only store what’s manually created 39

40. Best practices Don’t break the tree Use tags Don’t obliterate Don’t comment out code Don’t lock Build and test before every commit Build and test after every merge 40

41. References Continuous Delivery Jez Humble & David Farley Version Control by Example Eric Sink Git http://pcottle.github.io/learnGitBranching/ http://git-scm.com/book/en/ TFS http://vsarbranchingguide.codeplex.com/ 41

42. Review Version control in general Hide new functionality Incremental changes Branch by Abstraction Components Avoid branching Branch for release Branch by feature Branch by team Smart branchingBest practicesKeep trunk releasable 42

43. Questions? craig@mojosoftwareworx.com www.craigberntson.com/blog @craigber youtube.com/watch?v=aX4nf5Co16Q 43