Branches and
Merges are Bears, Oh My!
Craig Berntson
Chief Software Gardener
Mojo Software Worx
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
agenda
Version
control in
general
Avoid
branching
Smart
branching
Best
practices
4
What do you call it?
VCS
SCC
5
One file at a
time
File locks
RCS, SCSS
Centralized
Multi-file
Third
No network
Second
First
VCS generations
Distributed
Change sets
Merge before
commit
Commit
before merge
CVS, SVN,
TFS, VSS
Git, Mercurial
6
VCS Types
Centralized
Distributed
• CVS
• Subversion
• TFS
• Git
• Mercurial
• Telelogic
Streambased
• ClearCase
• AccuRev
7
Basic goals
• Work simultaneously
• Changes don’t conflict
• Archive every version of everything
8
Continuous delivery pipeline
Continuous
Integration
Automated
Acceptance
Testing
Automated
Capacity
Testing
Manual
Testing
Automated
Deployment
 Check into VCS often
 Every build is a potential Release Candidate
 Branching is an anti-pattern
 Lean: Branch is waste
9
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
Functional
• Files
• Components
• Subsystems
• 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?
Branching
was
poorly
planned
Large
changes
merged
Merge at
release Is
complex
• Delayed release
• Fewer features
• Lower quality
16
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.
2.
3.
4.
5.
6.
Create an abstraction over code that needs to be changed
Refactor code to use abstraction
Create the new implementation
Update abstraction to use new code
Remove old code
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
Branch for release
branching
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
Avoid branching
• Hide new functionality
• Incremental changes
• Branch by Abstraction
• Components
Smart branching
• Branch for release
• Branch by feature
• Branch by team
Best practices
Keep trunk releasable
42
Questions?
• craig@mojosoftwareworx.com
• www.craigberntson.com/blog
• @craigber
• youtube.com/watch?v=aX4nf5Co16Q
43