This document discusses trunk-based development and strategies for avoiding issues that can arise from branching code. It notes that branches often lead to merge conflicts and integration problems. Several experts provide recommendations, such as hiding new functionality through abstraction, iterative development with small releasable changes, componentization, and continuous integration to keep the code always releasable. Branching may make sense for large changes, spikes (experiments that may be thrown away), or new releases, but the document questions when branching is truly needed. Overall it promotes trunk-based development with fewer branches to reduce integration headaches.
11. syntac2c
conflict
class
BlaBlaBla
{
<<<<<<<
HEAD
public
void
bla(Bla
oldBla,
New
newBla)
{
oldBla.bla();
newBla.newBla();
=======
public
void
bla(Bla
oldBla,
Other
otherBla)
{
oldBla.bla();
otherBla.otherBla();
>>>>>>>
other
commit
}
}
12. seman2c
conflict
class
BlaBlaBla
{
public
void
something(Bla
bla)
{
<<<<<<<
HEAD
bla
=
bla.plus(14);
=======
bla
=
bla.minus(7);
>>>>>>>
change
//other
stuff
}
}
23. feature
branching
is
a
poor
man's
modular
architecture,
instead
of
building
systems
with
the
ability
to
easy
swap
in
and
out
features
at
run6me/deploy6me
they
couple
themselves
to
the
source
control
providing
this
mechanism
through
manual
merging
Dan
Bodart