Git Branching for Agile Teams

Why use Git + agile?

Git helps agile teams unleash their potential

Developer

How?

First, let’s review two pillars of agile

1

Build in narrow vertical slices

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

Modularity for the win!

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

2

Make releases a non-event

A big bang style release (everything at once)

means dependencies up the wazoo

Look familiar?

Just a few dependencies...

Do you hold everything in a local workspace until the entire user

story is implemented?

Nope

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…

Will frequent, incremental changes to the repo introduce

more risk?

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

Tell me more!

Developer

branching & merging is hell

In Subversion

branching & merging is easy

In Git

It’s all in the way data and histories

are tracked

Git stores data as a series of snapshots

(rather than changesets)

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

But enough about the technical

underpinnings

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

Atlassian devs create a branch for each

issue they work on

And it’s helping us deliver faster than

ever before

Keep the main line clean

Dev branches are like an isolation

chamber

No half-baked code on the main line

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”

Branch-per-Issue Workflow

for SaaS teams

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

It’s easy to control what is released to users and

what is held back

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

Builds fail on the integration branch,

not the release branch

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

Branch-per-Issue Workflow

for installed app teams

Multiple-version support

master

v 1.2

v 1.1

feature/DEV-30

In this model, master acts as an

“alpha” branch

Devs make branches off of master for

new development

And run CI, maybe use an integration

branch, etc.

Then a stable version branch is cut just

before release time

Create a bugfix branch off the release branch

and fix the problem there

Multiple-version support

master

v 1.2

bugfix-DEV 32

feature/DEV-30

Then cascade the fix back to the stable version

branch and master

Incorporating Agile Best Practices

Continuous Integration & Peer Review

Running CI on dev branches

All active branches are under test

Yes: all active branches

But that can clog the

build queue

Zzzz

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?

With Git, use pull requests to integrate

peer review into the workflow

Using pull requests1

2

3

Create request via UI or git request-pull

Review, revise, rinse & repeat

Approve & merge

Additional Considerations

Is “pure” continuous integration in a

branch-per-issue model possible?

Nope

For a CI purist, that matters

!

For a CI pragmatist, it doesn’t

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

https://www.atlassian.com/