Branch by abstraction
is a technique
for making large-scale changes
to a system
without disrupting
its operations.

(quitting a bad habit, changing a job, repairing software, etc.)

There may be
various parts
of the system
dependent on an old
pattern,
module,
component,
one wants to replace.

First,
an abstraction layer
needs to be created.

It captures interactions
between one of the parts
of the system
and an old component
one wants to replace.

We then gradually reroute
all interactions
from an old component
to the abstraction layer.

The abstraction layer
now acts as an interface
between the functioning parts
and the old component.

(one step at a time — pretending that everything is still the same even if it is not)

We then build a new component
that implements the features
required by one of the functioning parts.

We reroute the interaction
from the functioning part
through the abstraction layer
towards the new component.

We gradually phase out
the old component
towards the new component
rewriting the abstraction layer,
until we don’t need
the old component
anymore.

Once the abstraction layer
does not need the old component
and only uses the new component
to fulfil the same objectives,
to ensure operation of interdependent parts,
we can remove
the old component.

Using an abstraction layer
to allow multiple implementations
to co-exist in a system.

(Fake it till you make it)

Use the notion of one abstraction
and multiple implementations
to perform the migration
from one implementation
to the other.

Ensure that the system
builds and runs correctly
at all times,
so you can continue
to use Continuous Delivery
while you are doing
the replacement.

Look for as many ways
as possible
to make changes
gradually.

(remixed from the original source article on version control and branching in software development by Martin Fowler)