
Trunk-Based Development - solarengineer
https://trunkbaseddevelopment.com
======
kosma
This workflow, like all others, is just a formalization of some reality. The
reality is that many organizations and teams run on nothing but trunk - and it
more-or-less works on them. Some teams work by building blocks separately and
then joining them together; other prefer to hammer away on a problem all
together. Both approaches work. What worries me are emotional claims that the
other approach is fundamentally flawed, or that some git workflow is The One
True Way.

I've seen feature branches get stuck in review for _weeks_. I've seen trunk-
only developers not knowing how to merge a branch back to trunk. I've seen
trunks brought into a state of disarray and never fixed again. I've seen svn-
only devs get completely bogged down and confused by a git wofkflow.

Trunk-only is a reality. Not a reality some of us would want to live it - but
one that nevertheless exists.

~~~
stcredzero
_Trunk-only is a reality. Not a reality some of us would want to live it - but
one that nevertheless exists._

My background in Smalltalk made me accustomed to a style where everyone would
continuously merge everyone else's changes as they worked. This style makes
you aware of what your team mates are doing. In fact, it facilitates
communication pretty much when communication is most called for.

As always: context. The above approach is only going to work well, when there
is convenient high bandwidth communications between teammates. (Not only for
your version control, but also for communication between people.)

 _I 've seen trunk-only developers not knowing how to merge a branch back to
trunk._

Well of course. If they never had constant practice at merging, they wouldn't
be very good at it. Merging isn't trivial.

 _I 've seen trunks brought into a state of disarray and never fixed again._

Can't they roll back? This strikes me as a sign of badly designed process, or
developer incompetence. This should be seen as something like breaking the
build. (In a CI environment, it would be breaking the build, yes?)

~~~
chrisseaton
How does a team of Smalltalk developers work? How do you merge the binary
Smalltalk program image?

~~~
pjmlp
With time, Smalltalk also got its own version control tooling.

Monticello for example,

[http://www.wiresong.ca/monticello/](http://www.wiresong.ca/monticello/)

~~~
stcredzero
You could consider Monticello as one of the precursors of git.

------
Animats
_" The core requirement of Continuous Integration that all team members commit
to trunk at least once every 24 hours."_

Continuous integration is a means to an end, not an end in itself.

~~~
jfim
Indeed. There's a wide spectrum of software complexity and while committing to
trunk every day might be reasonable for lower complexity projects, it's
definitely not for higher complexity ones.

Having such a requirement also means that people can't undertake major
refactorings/rewrites of significant subsystems, leading to long term tech
debt.

~~~
dpark
In my experience, the "refactor the world in a separate branch" strategy is
always a giant mess. The initial work is perhaps simpler but the final merge
is always horrible and the full impact of breaks isn't found until the merge
is committed and you're stuck in "fix forward" mode because reverting is an
unacceptable choice due to the cost of merging.

I'm not sure the overall cost to the team wouldn't be lower if these sorts of
rewrites were done in place. (Also it's not really a refactoring if it's so
big you can't do it in branch.)

~~~
shubb
Not disagreeing, but a way to avoid this is to pull changes from the main
branch into the development branch every day, and write your new subsystem
'beside' the old one until it is ready to go. If you do it like this, it's not
much easier for the branched developers than working on the trunk - it's still
a moving codebase - but it does mean that if you cancel the rewrite there
isn't any pollution to the main branch.

~~~
dpark
The scenario you called out, where the rewriting work might be
abandoned/cancelled, is the only scenario I can think that makes a separate
branch _actually_ better. For cases where you're confident that the work will
not be cancelled, you have the same amount of work to push the rewrite back
into the main branch constantly as you do to constantly keep the child branch
in sync. i.e. If you can pull from the main branch into the rewrite branch and
build/test successfully, you can do the same in reverse. If you _cannot_ pull
from main into rewrite and build/test successfully, you're just postponing the
pain to the end when you'll dump it on the rest of the team when you finally
merge back and break everything in the main branch.

~~~
Vinnl
The disadvantage is that if your rewrite branch is halfway finished, you _can_
merge in the latest main branch, but if you do the reverse (which is exactly
as much effort), you're blocking the other developers until your rewrite is
done.

~~~
dpark
This is only true if you assume that the rewrite branch will be broken the
entire time. You're only blocking the team if your work will be unusable until
it's done. If that's the case, then you're also assuming at some point in the
future you'll complete the work, get everything working again, and then merge
everything back to master. It won't likely play out that way, though.

More likely is that:

* Your child branch will be test-broken and likely build-broken almost the entire time you develop.

* You'll stop taking frequent merges as they become painful because you're clearly not doing the work to patch everything up (and can't, because you've broken everything and likely can't even run tests).

* You'll be "almost done" and then spend three weeks trying to get everything building and testing again.

* You'll tell everyone to freeze checkins because you need to get merged and it's impossible because the branch is so far out of sync and and you're now conflicting on every tiny change.

* You'll finally push your merge back with half the tests disabled.

* The entire team will spend another month cleaning up the mess.

I've never seen a big feature/rewrite branch play out any other way.

~~~
Vinnl
True, in that case you're screwed :)

------
vemv
> Trunk Based Development is a key enabler of Continuous Integration, and by
> extension Continuous Delivery.

Quite false. How do you expect developers to take you seriously when you
essentially say "you can't properly do CI/CD with your current approach"? I
sure am enjoying CI/CD right now.

Trunk-based development seems to rely heavily on feature flags, which are a
huge source of complexity and inconsistency. Even when useful, they're
liabilities; not assets.

git-flow (and variations) is simple, enables consistent codebase state, makes
no assumptions about your codebase/infrastructure, and allows you to know the
exact state of production/staging.

Finally, as it happens so often with open source projects and initiatives,
first thing I should see is a big "Why". Why do I want this? Why are the
alternatives inferior?

~~~
qwer
> Quite false. How do you expect developers to take you seriously when you
> essentially say "you can't properly do CI/CD with your current approach"? I
> sure am enjoying CI/CD right now.

Quite true actually! :
[https://en.wikipedia.org/wiki/Continuous_integration#Everyon...](https://en.wikipedia.org/wiki/Continuous_integration#Everyone_commits_to_the_baseline_every_day)

~~~
__derek__
That's in a "Best Practices" section with this note at the top:

> This section contains instructions, advice, or how-to content. The purpose
> of Wikipedia is to present facts, not to train. Please help improve this
> article either by rewriting the how-to content or by moving it to
> Wikiversity, Wikibooks or Wikivoyage. (May 2015)

~~~
qwer
Are you questioning the daily part (continuous) or the mainline part
(integration)?

I'm also interested in your better source. Every book I've read on the subject
and the top 4 search results on google say the same thing.

~~~
__derek__
I'm not an expert, and I've read no books on the subject, so I'll refrain from
suggesting sources. The implication of my comment was that it's disingenuous
to use that link as proof when it's marked with the equivalent of a FIXME.

~~~
qwer
First off, I have no motive to be disingenuous. I really don't care how you
collaborate on software with your team.

Secondly, CI itself is considered a best practice. I don't know how you could
expect wikipedia to mark it as anything else?

Here's the top link from google if you really care to learn and aren't just
here to be a contrarian: [https://www.thoughtworks.com/continuous-
integration](https://www.thoughtworks.com/continuous-integration) . There is a
wealth of information on this subject that I promise all says the same thing.
We can argue about whether or not CI is useful, but the practice of
integrating continuously is in all the literature as well as the name itself.

------
rkaregaran
Puppet Labs’ recently published State of DevOps (2016) report specifically
calls out trunk-based development as a leading indicator of high performing
organizations [1].

[1] [https://puppet.com/resources/white-paper/2016-state-of-
devop...](https://puppet.com/resources/white-paper/2016-state-of-devops-
report)

~~~
hashkb
Amount of info required to download free report makes it not free. Can you
quote?

~~~
nhumrich
All you have to do is enter an email address. It doesn't even have to be a
real email.

~~~
Sir_Substance
It's pretty rude to ask every visitor to a free report to hand over contact
details. What are you planning to do with all those contact details?

I can only think of plans that range from annoying to malicious. None that are
good.

Don't normalize rude behavior. Conditionally free is not free.

~~~
brianwawok
It's their right as a producer to require email to view their content.

It's your right as a consumer to not want to make that trade.

Not rude. Rude is posting the raw file link to subvert the agreement or
complain about it on hacker news.

~~~
Sir_Substance
You have a very odd view of rights. It's /within their means/ as a producer to
require email to view their content. Just because you can do something doesn't
make it your right to do something. Doesn't make it wrong to do it either, but
that's god damn miles from a right.

In addition, just because you can do something doesn't mean you should, and
it's within my means to assert that anyone who asks for my contact information
but doesn't know me personally /definitely/ wants to spam me, there's no other
reason for them to ask for that information.

Being polite, spamming is rude. Being rude, people who send or enable spam are
worthless scum. I have no time for anyone who chooses willfully to be part of
that cycle.

My freedom to express that opinion actually /is/ a right[1].

[1] [http://www.un.org/en/universal-declaration-human-
rights/](http://www.un.org/en/universal-declaration-human-rights/)

~~~
foo101
> My freedom to express that opinion actually /is/ a right.

Sure, but [https://xkcd.com/1357/](https://xkcd.com/1357/)

~~~
Sir_Substance
It's odd that you would link that. From my perspective, I'm the one doing the
boycotting and showing of the door. How do you see it?

------
ZenoArrow
Correct me if I'm wrong but isn't this just a form of centralised version
control? If this is a better approach for many teams, perhaps this an
indication that DVCS weren't the silver bullet they were hyped up to be.

Aside from that, in my opinion the whole centralised version control vs.
decentralised version control, and all the variants thereof, miss the bigger
issue. Keeping track of the history of a file, and the authors of the changes,
is trivial for any version control system. The real challenge is in resolving
merge conflicts, and it's the low level of sophistication in merge tools that
is the real bottleneck here. That's why I think tools like Semantic Merge are
far more important to a development workflow than SVN vs Git vs Mercurial. It
relies on the merge tool understanding the structure of code rather than
treating it as an ordinary text file. Similar tools could be built for any
language that offers a 'compiler as a service' (such as RLS for Rust).

[https://www.semanticmerge.com/](https://www.semanticmerge.com/)

~~~
paul_h
SemanticMerge mentioned on the site: [https://trunkbaseddevelopment.com/game-
changers/#plasticscm-...](https://trunkbaseddevelopment.com/game-
changers/#plasticscm-s-semantic-merge-2013). It got it's name after I blogged
about it too - [http://paulhammant.com/2013/02/14/features-i-would-love-
sour...](http://paulhammant.com/2013/02/14/features-i-would-love-source-
control-tools-to-have/) \- and am still owed a beer.

~~~
ZenoArrow
Thanks for the links, I'm glad you identified this as an issue and inspired
further development of a solution (though I'm surprised you're owed a beer for
such an obvious name, must've taken all of about 5 seconds to think of that
one ;-) ).

Also found this article in the comments of your blog to be interesting:

[http://blog.plasticscm.com/2013/04/put-your-hands-on-
program...](http://blog.plasticscm.com/2013/04/put-your-hands-on-programming-
language.html?m=1)

This article you linked to was interesting too, is this a common workflow on
CI solutions now?:

[https://blog.snap-ci.com/blog/2013/11/07/automatic-branch-
tr...](https://blog.snap-ci.com/blog/2013/11/07/automatic-branch-tracking-and-
integration/)

------
cat199
With a sentence like:

" It has been a lesser known branching model of choice since the mid-nineties,
and considered tactically since the eighties. "

Given:

The Release Engineering of 4.3BSD
[https://docs.freebsd.org/44doc/papers/releng.html](https://docs.freebsd.org/44doc/papers/releng.html)
1989

concerning a key software system and part of software history, released in
1986, which states:

" For the 4.3BSD release, certain users had permission to modify the master
copy of the system source directly. ... The development phase continues until
CSRG decides that it is appropriate to make a release. "

,that the rcs tools of the time basically didn't even support branches
natively, and this model is followed to this day by the direct descendants of
this project

I'm prone to think that.. well. Hmm.

------
cygned
We currently use short-lived feature branches, merged via Pull Requests (+
review / automated testing) into the main development line. This way, we can
communicate changes in a detailed manner before they are added to the product
and make sure there is no unfished or bad code in the main branch. (The dev
team is small, 5-8 devs).

I don't see (yet?), what benefits TBD would provide in such a setup.

~~~
einrealist
With TBD you can reduce the overhead of coordination between committers.

Edit for clarification: "Branching in code", á la Feature Toggles is much
better, because everything around it can be automated. With CVS branches, you
shift that process into an earlier development stage where you need more human
collaboration. So TBD can shift the focus of collaboration to things that
matter more: the code.

~~~
cygned
I am very concerned that feature toggles add unnecessary complexity to the
code.

With Lisp Macros, for example, that would actually be quite elegant but in a
language like JavaScript, we'd end up with a bunch of if'a here and there,
wouldn't we? One might simplify it a bit with a different architecture,
though.

~~~
sydd
Long lived branches add complexity too, it's just hidden in GIT. The main
issue with feature branches are merge conflicts: they are the most evil
operation one can imagine. First you have your code, that you understand. Then
you have others code that you have no idea what it does, so first you need to
understand it. This might take hours when done properly. Usually people skim
over this part BC it's boring. This leads to superficial merges that leads to
very very evil and hard to find bugs. And these bugs are super hard to find in
git logs, since the merge commit is 2 or more people's code.

Whereas the alternative, feature toggles are much better: first you don't need
one for every small thing, add them to bigger features that take weeks to
implement. With a team of ~10 developers you should not need more than 2 at
one time (if you have more the management is at fault). Then feature toggles
enforce modularity: by principle you should use them in as few places as
possible, this will make the interface between the new feature and your
current app as small as possible. This is a good thing!

------
chvid
This is what I do when I can get away with it. Suitable for smallish teams.

All developers sit in the same branch; changes and conflicts are visible (and
resolved) immediately. All work takes place there including bug fixes.

When we branch out for release; the focus is on disabling unwanted features.
Actual development work + "hardening" is done in the main trunk before the
branch.

~~~
paul_h
Small teams like Google's 25000 devs and QA automators? :)

~~~
chvid
I think it can work well with maybe 10-20 people.

Depends on how well you software is modularised.

~~~
ithkuil
I assure you it works well with 25000 people, I've worked in such an
environment.

It seems to me that in the various threads I read here that there seems to be
a bit of misunderstanding. If you work on short lived feature branches and
merge them to trunk/master and other people branch new feature branches from
trunk/master and so on you might be just doing TBD without calling it that
way.

Many things are just common sense consequences of that, e.g. if other people
are spawning their feature branches from trunk/master; then you don't want to
merge something that breaks trunk/master, otherwise you'd be making the life
for your colleagues harder, since now they cannot know whether the code they
added breaks some tests or they are broken because somebody else broke them.

The feature-flag thing comes into play only when you want to break down a
larger feature into smaller branches, each landing in trunk/master before
continuing the next step. This get more important the more people can actually
make changes on the same part of the codebase that you big feature is going to
touch.

If it's only you that touches a section of your code base (and you can do it
because it's well modularized), you won't feel much pain of making your
feature branch last longer.

However, TBD shows its strengths precisely when the team grows; when you no
longer can make the assumption that only you will work on a given piece of
code.

~~~
twic
> you might be just doing TBD without calling it that way

I think this happens an astounding amount. In particular, i think Git Flow is
TBD with the names swizzled.

As far as i know, all the source control disciplines that people seriously
advocate involve:

1\. Developers working on local copies of the code

2\. A shared copy of the code where developers integrate their work when
they're done

3\. A copy of the code used to make releases, which is refreshed or recreated
from the shared copy

These copies get different names, which are meaningless labels. In TBD, the
shared copy is called 'trunk', and the release copy a 'release branch'. In
Flow, the shared copy is 'develop' and the release copy is 'master'. They're
just names. They don't matter.

The precise mechanism for moving work from local copies to the shared copy
varies, but not in a way which really matters. In TBD, developers usually push
straight to the trunk. If they're doing XP, they've done code review via
pairing. In some teams, there might be pre-merge code review through a tool
like Gerrit, Reviewboard, Phabricator, or some such, but still with an
expectation of a merge happening quickly. In Flow, i guess there are pull
reviews, but those are basically the same, a code review before merging. The
Not Rocket Science Rule is this, but enforced by a robot [1].

The mechanism for moving work from the shared copy to the release copy varies
a bit more. Strict CD shops release the trunk, but they will only push the
latest point on the trunk which has passed all the checks, which is a bit like
having an implicit branch. Conventional TBD cuts release branches. Flow does,
that, and then adds a bit of a dance around merging individual release
branches into the long-lived master branch, but it doesn't ultimately matter,
because any changes made on an earlier release branch have already been merged
back into develop. There's variation in where you fix urgent bugs: on the
shared copy, followed by a copy to the release copy, or on the release copy,
followed by a copy to the shared copy. I'm not sure that this is very
significant.

Which leaves the only significant tuneables being how often developers
integrate their changes, and how often the team makes releases. If you
integrate often, you get easy merges and rapid integration feedback. If you
integrate infrequently, you don't get those things. If you integrate more
frequently than you release, then you will need disciplined incremental
development, feature toggles, or some other way of making incomplete features
unavailable in production.

[1]
[http://graydon2.dreamwidth.org/1597.html](http://graydon2.dreamwidth.org/1597.html)

------
hashkb
The suggestion that feature branches hinder CD is just untrue, at least in my
experience. To me, this seems like a silly restriction to put on such a
critical tool (the scm) which is designed to support unlimited flexibility.

~~~
nhumrich
You must not understand what CD really means then, because full CD is
impossible with feature branches. CD means every commit gets built and
delivered all the way prod if it passes all tests. The key word is
"continuous" as in, every single commit. Branch based means you only deliver
once you merge. Merging is a manual step, so your not doing full-CD. The merge
is basically your "trigger" and your doing "delivery when I am ready"

~~~
joneholland
We deploy every commit in master and use short lived feature branches and pull
requests.

I would still consider this continuous delivery.

~~~
nhumrich
By "short lived", how short lived? Is the branch only for one developer? Or is
it shared? How do you enforce "short lived"? If the branches are not
collaborated on, you might be doing trunk based without realizing it.

~~~
hashkb
>you might be doing trunk based without realizing it.

Then trunk based is poorly named and apt to start a fruitless holy war. Nobody
wants too many people on a feature branch, or for one to live too long. (But
it happens, like rebranding an entire app or rewriting all the auth code,
which is a good thing to be able to do. )

Is there a threshold of time/collaboration that makes it not-CD?

~~~
nhumrich
My point is that the article says that branches for the purpose of WIP and
code review is OK as long as you don't share the branches. Trunk based is
trunk "based" as in your git "base". Your based on trunk, not a branch. It's
not called "commit directly to trunk only" development.

------
geocar
I described something that seems very similar years ago[1] (in response to
git-flow), however I've since come up with something better: I think knowing
how to get things live is important, and the _entire_ development process
should reflect that -- too many people have a "code cut" that takes days or
even weeks, and that's despite using the latest and greatest CI tools.

A lot of the problems may sound familiar: How do we test something? How do we
know it's good enough? We have a UAT step, but it doesn't find all the
problems, so do we need more tests? To be more careful?

My approach[2] turns the entire problem into a software problem, and it's
proving very successful to me (faster request turnaround, fewer problem
reports post-deploy, and so on). Being able to select a "git branch name" for
a specific user and get acceptance is powerful.

[1]:
[https://news.ycombinator.com/item?id=6125964](https://news.ycombinator.com/item?id=6125964)

[2]:
[https://news.ycombinator.com/item?id=11190540](https://news.ycombinator.com/item?id=11190540)

------
cwills
We have a smallish team working on web apps and use a trunk-based-development
branching strategy. Not really to do with helping CI/CD.

The advantage we see is that new developers can start developing as soon as
they clone the repository, without needing to switch to the 'development'
branch. This is particularly useful when on boarding new developers who are
inexperienced with Git. I found that when using Git Flow that the (stable)
master branch frequently ends up out-of-date when developers are required to
remember to merge into it releases into it.

Diagram of our branching strategy:
[https://gist.github.com/CameronWills/abf9e307669b1005c88ef82...](https://gist.github.com/CameronWills/abf9e307669b1005c88ef82e55102cd0)

~~~
paul_h
I looked at your diagram. I don;t think you're doing trunk based development.

------
ungzd
TLDR: instead of using diffs of changed lines in branches, use 'if' statements
in code to make Enterprise Continuous Integration gods happy.

~~~
UK-AL
The advantages of feature branches is that you can turn them on and off easily
without trying merge in, or revert and dealing with the resultant conflicts
this can cause.

Feature switches also have more advanced features like being able targeting
specific users, if you want a gradual rollout.

We use both feature branches and feature switches, since branches short be
very short lived. However large areas of development require months.

------
alkonaut
In subversion the only way I can possible develop with sanity is in an
"unstable trunk". Branch off releases N weeks before shipping, and have only
the requirement that trunk passes _automated_ tests while release branches are
manually tested. Obviously you don't release more than say once every month or
two, but that's more than enough for most.

I'm honestly not sure if the site is satire?

No one develops in long lived feature branches in svn (rather, everyone does,
but most only try it once before they realize the pain of trunk based dev is
much smaller than that of svn merging).

~~~
sydd
If you release only a month or 2 you are doing something really wrong (or need
to work based on some insane spec). Read the basics about CI and CD, read the
clean code book, read about modern organisation practices (e.g. Github
releases several times a day). Releasing every month or so is (thank God) a
relic of the old waterfall development times.

~~~
alkonaut
We do CI, not CD. Lots of software doesn't do CD and lots of it can't. Games.
Embedded. Desktop. Store-apps.

In my case it's large desktop software for structural engineering. Customers
don't want new versions more than 1-2 times per year because of deployment,
training and code compliance requirements. If we bork a release we have had
users make a long download+install again. We don't just deploy the fixed one
in prod to solve problems. Thats why a release goes through hundreds of hours
of manual testing.

Not to mention data: a feature is a new file format. If we ship one new
feature we basically ship a new format. Now you know why Autocad, Word and
Illustrator ships once per year and not once per commit.

I think what a lot of people (who presumably do web dev only) forget is that
web dev is just one of many software development disciplines, and a very young
discipline too.

I know of the practices you mention. I like clean code (both the book and the
idea). I'd do CD if I had a project some day that runs on a _server_. I hope I
won't have to do web dev any day soon though.

~~~
sydd
You can do CD without releasing, its not pressing the release button that
matters. CD means that you can press that button any time. Do small changes,
test continuously, work on master.

If you make small changes and test them (using automation - unit tests,
integration tests etc) you are catching bugs early, avoiding merge conflict
(the most evil operation of them all). This is not my idea, its in the clean
code book and its the basic of the CI/CD/TDD disciple.

And you can apply this to projects of all kind - we used it on the server, for
iOS projects where we had to wait for Apple for weeks etc.

~~~
flukus
This is an important distinction. Another one is that just because you aren't
deploying to production regularly doesn't mean you aren't deploying to other
environments.

------
jwatte
Trunk only goes well with continuous deployment.

If each increment in deployment is small enough, then you know exactly when
things break and rollbacks are easy.

The 3-2-1 system where you develop for 3 months, then merge for 2 months, then
debug in production for 1 month, is a real drag, and doesn't lend itself to
quick feedback at all.

For a software looking for product market fit with ultra short cycles, I would
absolutely choose trunk only.

For engineering projects in areas where cycles are months, or years, more
traditional branching makes more sense.

------
paul_h
One of the authors here. Ask questions :)

~~~
neandrake
Paul Hammant? Thank you for your blogs and thanks for putting this site
together, they're very informative. I work at a company that has been doing
"Cascade" model for close to a decade [0], very similar to TBD but not quite
the same. In addition to having a mainline trunk repo which everyone's work is
pushed to, we have started utilizing Phabricator in the past few years -- it
enables us to have short-running feature branches which aren't public to the
upstream repository but can be shared if necessary and used for review (I'm
not sure how similar this might be to GitHub flow? We use Mercurial).

[0]
[http://paulhammant.com/2013/12/04/what_is_your_branching_mod...](http://paulhammant.com/2013/12/04/what_is_your_branching_model/)

------
stcredzero
The Envy configuration management system for Smalltalk worked like this. As
you were working, you could see if someone had changed code "nearby" (same
class, same category, same protocol) and you could review it and merge it in.

Perforce provides something with the same effect. If you periodically get the
most recent revision, you can see files with collisions in your change sets,
then merge them in.

------
z3t4
I read Drunk-Based Development and was a bit disappointed. I can get awesome
ideas while very tired and usually write them down, but a few weeks later,
even though I was super exited when I wrote it down, it no longer makes any
sense ...

~~~
lucideer
I read Trump-Based Development...

------
xorcist
If there was indeed a superior way of developing software, why doesn't anyone
take this knowledge and out-compete for example Linux? It has literally
hundreds of branches of all kinds (stable branches, feature branches, test
branches), this should be easy pickings! Or out-compete Google or Microsoft
which, contrary to whats said in this article, use branches and probably in
all their big projects. Sorry, I don't buy it. I suspect that if you are
religiously against branches you will just have to re-invent them by some
other name.

------
joneholland
Trunk based development works well on any scm that sucks at branching.
Perforce, subversion etc.

But, on git, using GitHub-Flow is far superior.

The two poster children for TBD do not use git. Don't cargo cult their process
without understanding the unique problems they have that you don't.

Edit: downvotes on HN? This isn't Reddit, and I'm advocating github flow, not
git flow.

GitHub flow is trunk based development but with all work in feature branches
that live for less than s day or two, instead of branch by abstraction in the
core code. That's it!

~~~
vidanay
GitFlow and it's derivatives have very poor handling for continued bug fixes
of old released versions. It might be great for a truly continuous model such
as Facebook and Gmail where there is only "one true version", but in a case
where there is a current version and three old versions requiring bug fixes,
it fails miserably.

~~~
Horba
I've implemented GitFlow with multiple support versions. We just added a
"version" dimension to each of the main branches.

1.1/master 1.1/release 1.1/development

1.2/master 1.2/release 1.2/development

When we fix bugs in 1.x, we work off 1.1/development and merge into all later
versions.

This doesn't fit for a "web" or "continuous delivery" model. It does fit very
well for software houses with many customers on 6 monthly upgrade /
development cycles.

------
mpdehaan2
Developing on master is something I favor, with tagging for releases, though
it makes sense to create release branches if you are delivering software
packages (that others will install) and not just deploying it to .com
websites. Hotfixes can then be applied to both the maintaince branch and
master.

------
antoncohen
I think some people are getting confused about terminology between Trunk Based
Development[1], Git Flow[2], and GitHub Flow[3]. TBD and GitHub Flow are
nearly identical, basically if you use TBD on GitHub you use GitHub Flow. Git
Flow (not GitHub Flow) is a model that is all about cutting releases, and
supporting bug fixes to releases. Git Flow is nonsensical when doing
Continuous Delivery[4] of a web application.

If you are delivering web app code to production every day, it doesn't make
sense to cut versioned releases, with for example semantic versioning, instead
you just release the code that has passed tests. It also doesn't make sense to
have hotfix branches, because there is only one version in production[5], and
you release every day, so there is no need to backport a fix to older
versions, or do anything special to get a fix out quickly.

Trunk Based Development has branches. If you are working with a team you
pretty much never want to commit straight to master. The difference is that in
TBD the branches are short-lived and only exist for code review purposes.

This is what TBD would look like with GitHub and GitHub "forks".

    
    
        git remote -a
            origin    git@github.com:<your company>/<repo>.git (fetch)
            origin    git@github.com:<your company>/<repo>.git (push)
            <github username>    git@github.com:<github username>/<repo>.git (fetch)
            <github username>    git@github.com:<github username>/<repo>.git (push)
        git checkout master
        git pull # make sure you are starting with the latest master
        git checkout -b my-cool-feature # create a branch for you change
        vim <file>
        git add <file>
        git status # check that all expected code is staged
        git diff HEAD # review your changes
        git commit # write a meaningful commit message
        git fetch # get the latest changes from origin
        git rebase origin/master # put your changes on top of the latest changes from master
        git push <github username> my-cool-feature:my-cool-feature # push to a branch on your "fork"
        # Open a PR to merge from <github username>/my-cool-feature to origin/master
        # Once the PR is approved, use the GitHub UI to merge the PR into master
        git checkout master
        git pull # pull down your code that just merged to master
        git branch -d my-cool-feature # delete your feature branch
    
    

[1] [https://trunkbaseddevelopment.com/](https://trunkbaseddevelopment.com/)

[2] [http://nvie.com/posts/a-successful-git-branching-
model/](http://nvie.com/posts/a-successful-git-branching-model/)

[3]
[https://guides.github.com/introduction/flow/](https://guides.github.com/introduction/flow/)

[4] I'm defining CD to mean delivering to production at least once a day.

[5] Unlike on-premises software, with a SaaS product you only have two
versions: (1) what is in production, and (2) what is going out to production
(in staging, canary, etc.).

~~~
joneholland
This is all good, if you are on git.

Like I said in my other downvoted post... too many TBD zealots look at big
companies that use it sans branches, and assume that it is the one true way,
instead of understanding the larger picture (branches outside of git suck,
these companies don't use git for various reasons)

~~~
paul_h
Many of Google's 25000 Trunk-Based-Developers use Git on their local deevloper
workstations. They choose their own workflow on their own machine, and then
cooperate with the Mondrian submission rules when attempting to get their
commit(s) through code review and automated tests/lint/findbugs etc.

------
paulddraper
> Google do Trunk Based Development and they have 25000 developers and QA
> automators in that trunk

For some stuff, but

Is Android trunk-only? No.

Is V8 trunk-only? No.

Is Chrome trunk-only? No.

Those have release branches.

\---

Some software works with trunk-only paradigm, some does not. A rule of thumb
is whether your customer-facing distribution is SaaS/web-based.

If you're making Google Search, you do it in a trunk. If you're making Google
Chrome, you don't.

~~~
paul_h
> Those have release branches.

Some Trunk Based Development teams do "branch for release"
[https://trunkbaseddevelopment.com/branch-for-
release/](https://trunkbaseddevelopment.com/branch-for-release/) and some do
"release from trunk" [https://trunkbaseddevelopment.com/release-from-
trunk/](https://trunkbaseddevelopment.com/release-from-trunk/)

Google gave numbers themselves - 95% of their devs are in one big trunk
(formerly perforce, but re-written in-house in 2012). It's true that the open
source facing teams are outside that, and have processes that are less lock-
step than what they do in-house.

Android - Samsung, on each release (maybe not anymore), used to check all the
composite parts of Android into one big trunk for themselves. Back into their
Perforce.

> If you're making Google Chrome, you don't.

There's nothing stopping the Chrome team from doing Trunk Based Development on
Github, and accepting unsolicited pull requests like any other team.

~~~
paulddraper
You can have long lived release branches in "trunk-based development"?!?

In that case, I guess I haven't ever seen a branching strategy that _wasn 't_
"trunk-based." What would that even be?

~~~
qwer
Anything involving long-lived feature branches especially ones with multiple
collaborators, eg git-flow.

~~~
paulddraper
If I understand git-flow correctly, it's a trunk (develop) with a release
branch (master).

~~~
paul_h
We wrote about that: [https://trunkbaseddevelopment.com/alternative-branching-
mode...](https://trunkbaseddevelopment.com/alternative-branching-
models/#gitflow-and-similar)

~~~
paulddraper
Guess I should have RTFM.

Well written.

------
whyileft
Yup, as the other comment stated, this is par for the course in modern quality
software development. Its actually rather shocking to me to see my comment get
downvoted. The quality of the HN audience is declining dramatically. Feels
like all we have is a bunch of web agency lifers at this point.

~~~
icebraining
Feature flags are used by essentially every major software company. Hell, the
browser you're using to post this has quite a few. A bunch of major software
companies use them heavily as well.

You may disagree and think they're terrible, but calling their users just "web
agency lifers" is objectively incorrect.

------
revelation
No wonder they call it trunk, it's "branches in SVN are pure suck" elevated to
some sort of grand vision. Must have been feeling left out with all the cool
kids doing Git.

