git branching for agile teams
DESCRIPTION
Git helps agile teams unleash their potential. https://www.atlassian.com/TRANSCRIPT
Git Branching for Agile Teams
Why use Git + agile?
First, let’s review two pillars of agile
Waterfall: can’t release anything until everything is ready to release
DATA BA S E
BAC K E N D
F R O N T E N D
T E S T I N G
“big bang” launch
DATA BA S E
BAC K E N D
F R O N T E N D
T E S T I N G
MVP launch
Agile: something can get released fairly quickly
Or to put it another way…Potentially shippable, even without this piece
I have a roof!
The modular house may not have all its
components, but it’ll be move-in ready first
Modularity enables teams to have something testable
—and potentially shippable— much sooner
A big bang style release (everything at once)
means dependencies up the wazoo
Do you hold everything in a local workspace until the entire user
story is implemented?
That would mean an important practice for agile
teams wasn’t followed: continuous integration
Continuous integration, noun: Testing changes against the existing code base and in-progress changes from the team throughout the development cycle.
Sure CI is important, but…
YesHmm
But only if all those changes are piled on the primary code line
The idea is to push changes to the repo without de-stabilizing the primary code line
That’s where Git comes in
branching & merging is hell
In Subversion
branching & merging is easy
In Git
If SVN is a hand-drawn map,
Git comes with built-in GPS
Git uses triangulation to figure out what the
merged version should look like on its own
Git enables a dev to fully exploit the power of branch-and-merge
workflows
Why use a branching workflow?
Branching protects the main code line, and
supports an individual developer’s workflow
There are other benefits, too…
Clarity & traceability
If it’s been merged up, it’s ready to release. Easy!
The branch-per-issue model is the synthesis of:
“build in narrow vertical slices” +
“make releases a non-event”
The basic idea: a master code line with several
development branches running alongside it
A branch for every issueKeep master green
feature/DEV-30
feature/DEV-45
master
Experiment on your feature branch
Creating a branch
feature/DEV-30
master
Check your CI system to make sure you’re creating your dev branch from a clean commit!
Break all the tests on a branch without
disrupting teammates
Merge up when work is done
feature/DEV-30
master
With implementation complete, and CI passing, merge upstream! On some teams, the product owner acts as a “gatekeeper,” selecting branches for merge based on what they want to release.
The beauty of this branching model:
Code changes that are breaking tests on a dev branch
aren’t affecting master or impeding the team’s ability to
release from master
Now, a variation on that model:
Using an Integration Branch
The basic idea: a shared integration branch running between feature branches
and the master branch
But what if teammates merge incompatible changes upstream?
Surprise!
feature/DEV-30
feature/DEV-45
master
Now master is broken
And that’s sad
Some teams avoid this by using a shared branch
to integrate changes during development
Using an integration branch
integration
feature/DEV-30
master
feature/DEV-45
Merge all clean CI runs on the dev branch to the integration branch and run CI
If changes don’t play well with changes made by teammates, go back
and fix the branch
When implementation is done and CI on the
integration branch is clean, it’s ready to merge to master
Multiple-version support
master
v 1.2
v 1.1
feature/DEV-30
Multiple-version support
master
v 1.2
bugfix-DEV 32
feature/DEV-30
Incorporating Agile Best Practices
Continuous Integration & Peer Review
Running CI on dev branches
All active branches are under test
Yes: all active branches
Balance testing rigor and resource conservation
with manually triggered builds on dev branches
Triggering CI
master
v 1.2
feature/DEV-30
Developer
Automation
What about code reviews?
Using pull requests1
2
3
Create request via UI or git request-pull
Review, revise, rinse & repeat
Approve & merge
Additional Considerations
But shared integration branches and pulling updates from master
down to dev branches comes close to “pure”
And this workflow is so powerful for agile teams, it’s
wise to be practical
Here’s to easy releases, happy developers, and
getting Git right!
More info
1 http://atlassian.com/git
2 @Atlassian