3 ms·

> Bonus points for no PR’s and trunk driven development as that shows a very mature team. I'm not sure what Trunk Driven Development is, could you elaborate?

csmiller 5y ago
https://trunkbaseddevelopment.com/ https://trunkbaseddevelopment.com/
- Manuel_D 5y ago
  https://trunkbaseddevelopment.com/trunk1c.png https://trunkbaseddevelopment.com/trunk1c.png So trunk driven development means no PRs, until you decide you want to use PRs?
  - iampims 5y ago
    It’s trunk driven because there aren’t some long lived branches like ‘dev’ and ‘staging’ or ‘release-xx’ Feature flags can be used to gate features until they are ready, but all code is committed to trunk and is deployed to prod mostly continuously.
  - Izkata 5y ago
    Trunk-based development, as I've seen it explained in the past, isn't what that site describes. The way I understood it is, no branches at all, everything committed straight to trunk, and extensive use of feature flags to keep incomplete features hidden. Short-lived branches like that site's describing just sounds like a team that's adopted git pretty well, but not formalized usage into gitflow or similar...
  - the_gipsy 5y ago
    It's optional, I guess because so many companies or teams would immediately discard TBD if this wasn't addressed.
  - dgb23 5y ago
    What’s the benefit of having release branches without commits if you can just use tags? I guess the difference is mostly cosmetic?
- bluefirebrand 5y ago
  Okay now I'm wondering what the alternative is, because this just looks like "development" to me.
  - beanaroo 5y ago
    Gitflow, and its various flavours, has been a popular alternative. Though it seems trunk-based is considered the preferred standard due to emphasis on achieving a stable main branch, simplified pipelines and faster cycle times. This requires a bit more maturity to get right if I'm not mistaken as you need good automation, test coverage and code review practices.
    - bluefirebrand 5y ago
      I've never heard of Gitflow or anything. I've been doing this stuff for almost a decade and trunk based with short lived development branches is all I've ever seen. Bizarre.
      - dghlsakjg 5y ago
        Funnily enough, I've never heard of trunk based, but the flow described is what I have heard called the 'github flow'.
      - stephen_g 5y ago
        Yeah, it was pretty popular for a while but I doubt many people really do it because of it’s shortcomings. I guess if you spent most of your time in feature freezes trying to stabilise the upcoming release of your product, but I’ve often felt it’s better to either just have a few feature branches queued ready to merge once the master branch is tagged and released, or to branch master into a release branch once you have a feature freeze and only commit bug fixes to that. But then you have the annoyance of having to cherry-pick features between the branches.
      - svachalek 5y ago
        It's good that people experiment with new ideas I guess, but in my 27 years as a software developer all the progress I've seen is towards continuous integration and testing. The more branches and configurations there are, the slower development is and the lower overall quality is. Sometimes there are advantages to counterbalance that, and if you've got a huge team and a huge user base it may be worth the cost. But a strong default bias towards less branches, less options, test more often, merge sooner, deploy sooner has always worked better than fancy alternatives.
beebmam 5y ago
Virtually all game companies use Trunk Based Development, in my experience, including many very large studios. (Outside of game engine development, which isn't really done by game studios anymore with a few exceptions)
- Yhippa 5y ago
  Interesting, I wonder if that's why you see insane build numbers like 1.2.4045.26836?
  - hinkley 5y ago
    I suspect you'll find that two of those numbers are decided by committee, one by a human, and the other by the build system. There's good odds that it's the 26836th build, the 4045th snapshot, and the second time they've broken the file format. (or the 2nd expansion, or both)
dilyevsky 5y ago
I’m assuming based on gp everyone merges into master, no one reviews each other commits. Very uh.. mature Btw trunk based in general can still have short lived branches and prs. That’s what most public projects on github are doing
bredren 5y ago
Do you follow a style of git behavior now? I transitioned from purely git flow projects to most of my time on a trunk-based team this year. Pretty striking difference.

csmiller 5y ago

https://trunkbaseddevelopment.com/ https://trunkbaseddevelopment.com/

Manuel_D 5y ago
https://trunkbaseddevelopment.com/trunk1c.png https://trunkbaseddevelopment.com/trunk1c.png So trunk driven development means no PRs, until you decide you want to use PRs?
- iampims 5y ago
  It’s trunk driven because there aren’t some long lived branches like ‘dev’ and ‘staging’ or ‘release-xx’ Feature flags can be used to gate features until they are ready, but all code is committed to trunk and is deployed to prod mostly continuously.
- Izkata 5y ago
  Trunk-based development, as I've seen it explained in the past, isn't what that site describes. The way I understood it is, no branches at all, everything committed straight to trunk, and extensive use of feature flags to keep incomplete features hidden. Short-lived branches like that site's describing just sounds like a team that's adopted git pretty well, but not formalized usage into gitflow or similar...
- the_gipsy 5y ago
  It's optional, I guess because so many companies or teams would immediately discard TBD if this wasn't addressed.
- dgb23 5y ago
  What’s the benefit of having release branches without commits if you can just use tags? I guess the difference is mostly cosmetic?
bluefirebrand 5y ago
Okay now I'm wondering what the alternative is, because this just looks like "development" to me.
- beanaroo 5y ago
  Gitflow, and its various flavours, has been a popular alternative. Though it seems trunk-based is considered the preferred standard due to emphasis on achieving a stable main branch, simplified pipelines and faster cycle times. This requires a bit more maturity to get right if I'm not mistaken as you need good automation, test coverage and code review practices.
  - bluefirebrand 5y ago
    I've never heard of Gitflow or anything. I've been doing this stuff for almost a decade and trunk based with short lived development branches is all I've ever seen. Bizarre.
    - dghlsakjg 5y ago
      Funnily enough, I've never heard of trunk based, but the flow described is what I have heard called the 'github flow'.
    - stephen_g 5y ago
      Yeah, it was pretty popular for a while but I doubt many people really do it because of it’s shortcomings. I guess if you spent most of your time in feature freezes trying to stabilise the upcoming release of your product, but I’ve often felt it’s better to either just have a few feature branches queued ready to merge once the master branch is tagged and released, or to branch master into a release branch once you have a feature freeze and only commit bug fixes to that. But then you have the annoyance of having to cherry-pick features between the branches.
    - svachalek 5y ago
      It's good that people experiment with new ideas I guess, but in my 27 years as a software developer all the progress I've seen is towards continuous integration and testing. The more branches and configurations there are, the slower development is and the lower overall quality is. Sometimes there are advantages to counterbalance that, and if you've got a huge team and a huge user base it may be worth the cost. But a strong default bias towards less branches, less options, test more often, merge sooner, deploy sooner has always worked better than fancy alternatives.

beebmam 5y ago

Virtually all game companies use Trunk Based Development, in my experience, including many very large studios. (Outside of game engine development, which isn't really done by game studios anymore with a few exceptions)

Yhippa 5y ago
Interesting, I wonder if that's why you see insane build numbers like 1.2.4045.26836?
- hinkley 5y ago
  I suspect you'll find that two of those numbers are decided by committee, one by a human, and the other by the build system. There's good odds that it's the 26836th build, the 4045th snapshot, and the second time they've broken the file format. (or the 2nd expansion, or both)

dilyevsky 5y ago

I’m assuming based on gp everyone merges into master, no one reviews each other commits. Very uh.. mature Btw trunk based in general can still have short lived branches and prs. That’s what most public projects on github are doing

bredren 5y ago

Do you follow a style of git behavior now? I transitioned from purely git flow projects to most of my time on a trunk-based team this year. Pretty striking difference.