Craig BerntsonChief Software Gardener

Mojo Software Worx

Branches and Merges are Bears, Oh

My!

Ego stuff

• Chief Software GardenerMojo Software WorxSalt 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

agenda

Version control in general

Avoid branching

Smart branching

Best practices

4

What do you call it?

VCS

SCC

5

VCS generationsFi

rst No network

One file at a timeFile locksRCS, SCSS

Seco

nd CentralizedMulti-fileMerge before commitCVS, SVN, TFS, VSS

Third Distributed

Change setsCommit before mergeGit, Mercurial

6

VCS Types

Centralized• CVS• Subversion• TFS

Distributed• Git• Mercurial• Telelogic

Stream-based• ClearCase• AccuRev

7

Basic goals

• Work simultaneously• Changes don’t conflict• Archive every version of everything

8

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

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

Why teams branch

Physical• Files• Components• Subsystems

Functional

• Features• Logical changes• Bug fixes• Enhancements• Patches• Releases

11

Why teams branch

Environmental

• Build and runtime environment• Compilers• Windowing systems• Libraries• Hardware• Operating systems

Organizational

• Activities• Tasks• Subprojects• Roles• Groups

12

Why teams branch

Procedural

• Team’s work behavior• Policies• Processes• States

13

common scenario

14

Common scenario

15

Why is this bad?

Merge at release Is complex

Branching was poorly

planned

Large changes merged

16

• Delayed release• Fewer features• Lower quality

How do you fix this?

• Avoid branching• Smart branching

17

Avoid branching

Develop on trunk

Hide new functionality

Incremental changes

Branch by abstraction

Components

18

Hide functionality

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

19

Hide functionality

20

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

Incremental changes

22

Branch by abstraction

1. Create an abstraction over code that needs to be changed2. Refactor code to use abstraction3. Create the new implementation4. Update abstraction to use new code5. Remove old code6. Remove abstraction layer if not needed

23

Branch by abstraction

24

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

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

Issues with components

• Components everywhere• God components• Teams are responsible for individual components• Increased dependency management

27

Branch by abstraction

28

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

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

When you need to branch

Smart branching

Branch for release

Branch by feature

Branch by team

31

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

Branch for release

33

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

Branch by feature

35

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

Branch by team

37

Smart branching

• Branches should be short lived• Merge often• Requires good project management

38

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

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

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

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 branching

Best practices

Keep trunk releasable

42

Questions?

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

43