Hacker News Reader

Comment by joneholland | Hacker News Reader

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!

View on HN

From the page:

Depending on the team size, and the rate of commits, very short lived feature/task branches are used for code-review and build checking (CI) to happen before commits land in the trunk for other developers to depend on. This allows and engage in eager and continuous code review of contributions before they land in the trunk.

This sounds roughly like what you are advocating.

The resources about GitHub-flow that I've seen don't put emphasis on the lifetime of branches, only on them being finished at some time, with the completion of a feature, and being deployed immediately after being reviewed.

We don't put hard limits on our branch lifetime, but we groom stories with a goal to make them small enough so that the feature branch is very short lived.

Based on the quote, it sounds like the authors of this submission might count what you do as a form of "trunk-based development" then.

yup

Which two poster children?

Trunk Based Development is also "all work in feature branches that live for less than a day or two". One small difference to Github-flow though: https://trunkbaseddevelopment.com/alternative-branching-mode...

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.

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.

I'm not talking about git flow.

Who are your two poster children? Because in my mind it's Amazon and Google, who both use git

In the article it was google (perforce) and Facebook (mercurial with hacks).

Both are massive mono repos.

At Amazon they were mostly perforce when I was there. Granted that was a few years back.

I would say the bigger the repo becomes (in terms of # of collaborators) the more important trunk based becomes regardless of SCM choice. Mainly because merging many branches for many teams becomes very tedious and hairy. By the time you resolve all the merge conflicts, someone else will commit a merge and you'll have to resolve conflicts all over again.

I agree, which is also why I think monorepos are an anti pattern.

If two teams are working on two parts of an app that could be in different repos then they would have no conflicts while in a monorepo.

Wouldn't you have the same problem with trunk though? If you commit at the same time as someone else, and they push their changes first, then you'll have to resolve any conflicts before you push.

It seems that trunk based development is merely a means of enforcing extremely short lived "branches".

Google doesn't use perforce anymore. They have a custom in-house SCM that has various interfaces wrapped around it. I'd recommend this video that describes it.

https://m.youtube.com/watch?v=W71BTkUbdqE

Piper is awesome, but it's not unreasonable to think of it as Perforce if you designed and built Perforce to scale to handling all of Google in one repo. It has basically the same set of nouns and verbs. citc is the really magical bit, UX wise, as it's like you had a Perforce view set up for our entire repo but never actually had to sync it manually. Just navigate to a file and start hacking.

The paper that corresponds to the talk includes numbers on that (I forget if they're in the video).

http://m.cacm.acm.org/magazines/2016/7/204032-why-google-sto...

(note: I work at Google and absolutely love our SCM and other dev tooling)

Amazon (today) maintains a git repo per package, though in theory there's no reason why it has to stay git (or even be homogenous). Each application is a set of versioned artifacts that can be updated, forked, or merged together so long as the whole set builds together.

Sounds like they still use Brazil.

I've never understood the mono repo argument. With something like Brazil (or even sonatype nexus), you end up in a much stronger place for guaranteeing consistency and immutability in your builds.

Reply on news.ycombinator.com