5 ms·

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 poste

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!

nhumrich 10y ago
Who are your two poster children? Because in my mind it's Amazon and Google, who both use git
- joneholland 10y ago
  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.
  - nhumrich 10y ago
    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.
    - joneholland 10y ago
      I agree, which is also why I think monorepos are an anti pattern.
      - hamandcheese 10y ago
        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.
    - hamandcheese 10y ago
      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".
  - kyrra 10y ago
    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 https://m.youtube.com/watch?v=W71BTkUbdqE
    - jsolson 10y ago
      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-stores-billions-of-lines-of-code-in-a-single-repository/fulltext 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)
  - dastbe 10y ago
    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.
    - joneholland 10y ago
      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.
vidanay 10y ago
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 10y ago
  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.
- joneholland 10y ago
  I'm not talking about git flow.
detaro 10y ago
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.
- joneholland 10y ago
  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.
  - detaro 10y ago
    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.
    - paul_h 10y ago
      yup
paul_h 10y ago
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-models/#github-flow https://trunkbaseddevelopment.com/alternative-branching-mode...

nhumrich 10y ago

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

joneholland 10y ago
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.
- nhumrich 10y ago
  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.
  - joneholland 10y ago
    I agree, which is also why I think monorepos are an anti pattern.
    - hamandcheese 10y ago
      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.
  - hamandcheese 10y ago
    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".
- kyrra 10y ago
  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 https://m.youtube.com/watch?v=W71BTkUbdqE
  - jsolson 10y ago
    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-stores-billions-of-lines-of-code-in-a-single-repository/fulltext 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)
- dastbe 10y ago
  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.
  - joneholland 10y ago
    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.

vidanay 10y ago

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 10y ago
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.
joneholland 10y ago
I'm not talking about git flow.

detaro 10y ago

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.

joneholland 10y ago
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.
- detaro 10y ago
  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.
  - paul_h 10y ago
    yup

paul_h 10y ago

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-models/#github-flow https://trunkbaseddevelopment.com/alternative-branching-mode...