8 ms·

Trunk-Based Development

90 points by DLion 3y ago

redcobra762 3y ago
Wait so no develop branch? The utility gained by having “what’s in production” and “what we’re working on” as separated feels hard to part with.
- willsmith72 3y ago
  if that's the only reason for the branch, you can just as easily determine which commit is on which environment with tags
  - geraldwhen 3y ago
    Or put the sha in the version number.
  - redcobra762 3y ago
    So if the “deployed branch” were really just a “tag”, that would fit trunk based development? Because that’s basically what git is doing. It’s not like there are two sets of files anywhere, afaik. My understanding of this though is that there isn’t supposed to be a difference between “what we’re working on” and “what’s deployed”, which I think then means you don’t really do “long term” development.
    - deleted 3y ago
      [deleted]
  - ToJans 3y ago
    I've been working on my product for over 8 years, sometimes alone, sometimes with a tiny team. I have a mono-repo with one master branch - that auto-deploys to test - and one release branch that auto-deploys to staging. I can hot-swap my staging and production environment with the click of a button. Simple, and it allows us to deploy a hotfix of needed, and we've done some major work on master that needs to be validated first... But,... It all depends on your context and your needs...
    - willsmith72 3y ago
      the hotfix is extremely useful but you have to be so so careful when you're missing up history, when it comes to db migrations and api compatibility
    - andix 3y ago
      Sounds neat, but I still think complexity is removed if the deployment is not directly linked to the code repository. For me the code repositories purpose is to build software, and operation is not it's responsibility. I prefer having a gitops repository that describes the environment. Completely decoupled from the source code repository. If some automation directly from the source repository is required, a CI job can automatically update the gitops repository and trigger a deployment. Separation of concerns.
- ec109685 3y ago
  It’s still trunk based development even if a feature branch / tag is created that will match production.
  - andix 3y ago
    I'm convinced that development and operation (deployment) should be thought of separately. The branching model for the code should only serve the purpose to create a working product (artifacts of some kind). Those artifacts should be versioned (can be semver, or just the short hash of the commit, or anything else). Once something is ready for deployment it can be deployed, in the best case this is just clicking one button or one CLI command. Developers shouldn't be afraid that one wrong commit can automatically just go to production.
- fritzo 3y ago
  I think the idea is that, rather than storing two versions of the code in your version control system, you store both versions in trunk and gate with a feature flag.
- sowbug 3y ago
  Your local repo is the equivalent of the development branch. Yes, that means you don't collaborate with others on development branches, or go for weeks committing only to a branch. If you save up a bunch of work, dump it on the main branch, then start a new development branch that lets you escape from the integration pain of your big merge, then trunk becomes a dumping ground that nobody wants to (or can) work on.
  - edgyquant 3y ago
    Seems strange. Sometimes we’ll have feature branches that are made up of different parts, with different devs collaborating to build those parts out. For this I don’t see a way around having some staging branch with two devs sending PRs to before you work out all kinks and merge the staging branch back into main
    - jozzas 3y ago
      This is the hardest part about trunk based development - changing your way of thinking. Everything needs to be decomposed into much smaller changes, and you need to think about the impact of each of them being deployed into production (since that will happen). New features should exist behind some kind of feature gating or dial-up capability, or a new API version with restricted access, etc. That seems painful but it's less painful than merge hell or deploying a change with a massive delta to production and needing to roll it back and unpick what went wrong.
      - redcobra762 3y ago
        I dunno if I’m fully onboard, but anything that forces devs to think in terms of smaller changes will always get my attention.
    - sowbug 3y ago
      "before you work out all kinks and merge the staging branch back into main" Working out all kinks on an isolated branch is very hard to do. You need to integrate to hear the screams of the team you never expected your change would affect. So your choice is to integrate commit by commit on trunk, or to wad it all up into a single waterfall release from your branch to trunk, and then spend hours/days bisecting to find which commit caused the screams. As jozzas said, feature flags enable your code to safely lurk on trunk before it's functional.
- andix 3y ago
  If there are multiple environments it quickly gets impossible to keep track of "what's in production" as a branch. Two possible solutions: Git tag everything that's getting deployed. Or just keep track of the commit hash that is deployed.
tomoyoirl 3y ago
[flagged]
- leetrout 3y ago
  * Jenkins worker
  - tomoyoirl 3y ago
    Maybe if they spun up a new cluster with new hostnames it’d say that. It doesn’t.
- 000ooo000 3y ago
  Then you met with the Scrum Master to discuss planning?
  - deleted 3y ago
    [deleted]
- striking 3y ago
  As of February 2016, references to "slave" in documentation began to be replaced with "agent": https://issues.jenkins.io/browse/JENKINS-27268 https://issues.jenkins.io/browse/JENKINS-27268 The comment I'd make is that this appears to have been settled nearly eight years ago in this particular context, and that maybe you should give it a rest.
  - woooooo 3y ago
    It was "settled" in that we're all agreed it's obviously incredibly stupid but not worth fighting over and getting called racist. The good news is that "master vs mainline" was so embarrassing that even the people who push this stuff realized they overreached and have settled down since.
  - tomoyoirl 3y ago
    You seem to misunderstand. My objections to the change are minimal. It is the incompleteness of the change that is remarkable.
Flux159 3y ago
I think that good tooling is a necessity to do trunk based development well - not just CI/CD and testing on PRs, but also being able to have stacks of commits in multiple PRs before landing as a whole (from ghstack, Sapling, or Graphite). Having worked at Facebook before where managing stacks of diffs was far better than GitHub, I wish that more of the improvements to the developer workflow could be open sourced beyond Sapling now that Phabricator is no longer supported.
- lima 3y ago
  Stacking with Gerrit works beautifully. Can only recommend giving it a try!
- ramraj07 3y ago
  Which of those three tools works best on GitHub? Ideally without paying (not that I mind paying but it’s impossible to get the approval for some niche tool like this)
  - Flux159 3y ago
    I’ve used both Sapling cli & Graphite with github repos without having to pay anything. They both have extensions for vscode as well that makes it easier to manage stacks.
- idlephysicist 3y ago
  I agree with what you said but I'd further refine it by saying not just having testing and CI but actually having "high" test coverage and tests that actually test the code.
mlhpdx 3y ago
There is no “right” or “best” way to do this job, right? But kudos for taking a position and articulating it.
mgraczyk 3y ago
Google and Facebook both use trunk based development for nearly all code at both companies. This guide advises you to consider trunk based development if your release cycles are less than ~4 weeks. I'd suggest doing it no matter what. The only place where I've run into problems with this was managing very long term hold outs where we wanted to avoid changing user visible behavior. Instead of branches, we maintained literal copies of all the files for multiple years. I don't think revision control is the right place to solve that problem though, because there were no clear service boundaries to decide what things to pin, we just did it in an adhoc way.
- ec109685 3y ago
  How did the hold back end up working out? Was the learning worth the hassle?
  - mgraczyk 3y ago
    Yes for sure. In some sense, I learned more from these holdouts than from anything else I've ever done in my career.
- Scubabear68 3y ago
  I am amazed at how much “process” developers these days have to adhere to, including complicated branching strategies plus a whole lot more. So much time wasted doing busy work. I have always been happiest in a trunk-based dev model, but in many orgs it is heresy to even mention it.
  - dboreham 3y ago
    Imho this is an emergent property from the fact that most folks don't understand what they're doing. If they did, then every time Mr Dilbert pointy head dude comes up with some nonsense process, they'd explain why it isn't beneficial. Instead most of the time everyone nods. Lawyers don't have crazy people telling them how to write contracts. Doctors don't have people telling them how to saw off legs. Teachers kind of do have dumb people telling them how to teach though.
forrestthewoods 3y ago
I’ve been pretty happy with trunk-based development in my job. It’s simple and reliable. I don’t miss alternatives in any way. A significant amount of Git-isms are based around Linux kernel needs. Which is great. But closed source and typical open source needs are pretty different, and much simpler.
thaumaturgy 3y ago
Nice to see this getting some treatment. It's been my preferred source control strategy at several places now -- both small and large, though nothing so large as Facebook. It has its limitations, but for the the 90+% of places that aren't operating at Facebook scale, it's probably the right choice. It doesn't eliminate merge hell, but it does localize it, making it a lot easier to resolve conflicts without accidentally undoing somebody else's work. It's especially well-suited for any projects that are in constant-iteration mode, where there's a steady stream of bugfixes and new developments getting deployed daily (or even multiple times a day). You can even manage longer-lived branches after a fashion: the cleanest pattern seems to be to capture your changes into a patch, revert your branch to the commit immediately before your changes, merge/rebase main, then apply your patch on top. This is bad and lame because it rewrites history and requires a force push to get it into the remote, but it's also nice because it keeps your changes at the tip of the branch and makes review a bit easier in e.g. GitLab. Every small shop I've worked with that has tried to use more complex branching models eventually hoses the repo and ends up burning a lot of dev hours one day trying to make sense of a git log that looks like a diagram of network sorting.
- reissbaker 3y ago
  FWIW, Facebook also uses trunk-based development, so it works at that scale too!
- striking 3y ago
  A lot of the rebase/merge hell I've seen has been more or less resolved with the introduction of a merge queue. Granted, there are other issues that crop up (notably, flaky tests go from being an annoyance to life-threatening) but at least bigger changes don't get blocked and stay blocked.
yellowapple 3y ago
Seems very similar to Fossil's philosophy, which I've started to appreciate.
pard68 3y ago
I work at a place that has a few very large code bases, we use trunk-based. I will never go back, "what is your git workflow?" Is a question on my list of things to ask potential employers now and the only good answer is "trunk". So much mental load is wasted on these other strategies.
- pylua 3y ago
  It gets even worse — convoluted GitHub action templates that no one can debug, attempting to impose on every newly created repository. The projects at my company that use the complicated actions with gitflow are slower and less efficient. When I release a service at my company I just do trunk based ,but I have to redo the GitHub actions initially to save it from itself. Over the long run it saves me a lot of time.
- giancarlostoro 3y ago
  I'm not really sure what the mental load is but having gone to Trunk felt like a mistake, I don't know if it was just designed wrong at the last place I worked at, but we have to do more than normal per release, and I'm not a fan of squashing commits, it means I can't just go back to a branch and merge the development branch back into it, I have to check out a brand new branch. I also preferred having "master / main" and "development" because if QA claims there's a bug introduced during the development phase, you can figure out if it's already in the main production branch or if it truly was introduced during development. Which is something you can't really do with "trunk based development" it's like all these people who praise it should just switch to SVN instead?
  - andix 3y ago
    I think you're mixing up a lot of things. Trunk-based development also doesn't mean that you are not allowed to create branches. And you can still check out an older version.
    - giancarlostoro 3y ago
      They deleted every branch on merge, and had us rebase for merges. Before trunk based development was introduced, everyone on the team understood what the flow was. Afterwards, whichever developer was picked to cut a release, took half a day to figure it out to make sure they didn't screw up. I would have rather just used SVN and called it a day.
gnabgib 3y ago
Could use a (2015) - according to the front-matter on the repo (in the master branch, natch). It's been posted here a number of times, it was particularly popular the first posted time in 2017[0] (199 points, 208 comments). [0]: https://news.ycombinator.com/item?id=13514289 https://news.ycombinator.com/item?id=13514289
TruthWillHurt 3y ago
It's the same fucking thing. You just painted each track different color and thickness. So people don't merge branches to main branch, but tag releases from it. ok. But they still need to merge their changes to main first, right? Same fucking thing, wrapped in execucrap.
danielvaughn 3y ago
We’re considering this at my org. We’ve got a distributed backend with about 2 dozen repos, with a big web of dependencies between them. When you need to make a breaking change to one that is depended on by a lot of the other repos, it can be incredibly tedious to fix all the downstream effects. Using trunk would resolve it, but would also of course introduce other issues.
- golergka 3y ago
  In my experience, just moving them all to one monorepo would already solve a lot.
- andix 3y ago
  Multi-repo software products maintained by the same team are another thing I'm probably never going to understand. In reality the components are never fully decoupled and nearly always released together. When splitting up a product into multiple repositories a lot of new problems are created. Every sub-project needs to be testable completely independently and then in a later stage integrated with the other components and tested again. With multi-repository it's much harder to isolate a change over multiple components into one PR and test those changes together. Instead they develop separately and after some time many of those changes are tested together. It's just making the feedback loop longer without any added value.
  - codethief 3y ago
    > When splitting up a product into multiple repositories a lot of new problems are created. Every sub-project needs to be testable completely independently and then in a later stage integrated with the other components and tested again. While I'm a fan of monorepos, that issue doesn't completely disappear there, does it? I mean, if the monorepo contains the code for N artifacts (say, N, microservices that interact with one another), you will still have to make sure that the master version of microservice 1 plays nicely with the currently deployed version of microservice 2.
    - andix 3y ago
ChrisArchitect 3y ago
(2017) Some recent discussion: https://news.ycombinator.com/item?id=34733805 https://news.ycombinator.com/item?id=34733805
tripdout 3y ago
There's a workflow where you commit to each release branch? I genuinely did not know that. I thought working on individual branches, merging to master, and then cutting the release branch from there (to merge back into master if any changes were found during testing) was the only major way people actually did things.
c-hendricks 3y ago
I've been pushing and using trunk for years. To think someone looked at the graph for git-flow and said "yes please" is madness. That said, trunk-based is probably not great if you actually do need to support multiple versions of a piece of software simultaneously.
- andix 3y ago
  I'm not sure if any branching strategy helps supporting multiple software versions simultaneously. There is a reason why "rolling releases" are the default now. For a short while it may work to just merge bugfixes to older versions. But after a while the changes to older versions need to be done independently. Implementing a fix for three versions will just take three times longer than for one version very soon.
brirec 3y ago
TFA advocates strongly against long-lived branches, which I understand and agree with, but with one exception: major/LTS versions should have their own branch, so that hotfixes can be cherry-picked from main (or, rarely, applied directly to the major version branch.
- sowbug 3y ago
  That's right. It's important to be able to reproduce released builds with minor patches, and branches are the right tool for that job. But resist the temptation to fix that CVE on the release branch and then upstream it, because then you're once again doing branch development, treating trunk like a garbage can.
AdrianB1 3y ago
How does this look like when you have multiple active versions of an application? In some cases there are apps deployed in different environments (or to different clients) in different versions and having a single place to make all commits is not feasible. How do things that have LTS versions in parallel with "regular" versions organize?
- andix 3y ago
  How I've done it: Just tag the commit that is used to build a release. If you need to add a fix to an older release, create a branch from the tag. Do the changes trunk based on this branch, then tag and release. If needed just repeat it. I'm convinced that complex branching strategies never magically solve any issues. They just confuse many people until every successful release feels like dark magic.
  - AdrianB1 3y ago
    Why not keep a permanent, separate branch for each version that is still maintained? And do trunk on each version branch.
    - andix 3y ago
      I don't like long lived branches. For me a branch is work in progress. Work should be finished, once finished the branch should be deleted. If you start work again, create a new branch. But sure, if supporting an older release is some kind of ongoing trunk-based process this is also a viable solution.
sonaj 3y ago
I like TBD. I've always found the difficulty was in getting people to use feature flags, and then also managing those flags. https://trunkbaseddevelopment.com/feature-flags/ https://trunkbaseddevelopment.com/feature-flags/
rplst8 3y ago
No thanks. I've worked on teams using trunk based development before and I ended up being the one having to fix other people's messes, deal with them losing work, and the absolute hell of trying to find where a bug was introduced. The only people I really want on my team are those that understand Git. And even when there are team members that don't understand Git, I sure do and can pretty easily un-eff any situation someone gets themselves into. Seriously, Git is actually simple and it should be a fundamental CS class taught at all universities.
- rplst8 3y ago
  P.S. sitting down and learning git was probably the single most useful activity I've done on my 23 year career as a dev.
- sanderjd 3y ago
  > the absolute hell of trying to find where a bug was introduced What does this have to do with a trunk based branching strategy? > Seriously, Git is actually simple and it should be a fundamental CS class taught at all universities. I'm fairly confused by this, as it doesn't seem to contradict OP, which is about using git...
- forrestthewoods 3y ago
  > deal with them losing work The fact that is ever possible is a damning indictment on Git > Git is actually simple The clearest evidence that something isn’t simple is when there are thousands of people yelling in frustration that it’s simple. Things that are actually simple don’t require a never ending stream of guides and tutorials. The world can do much, much better than Git.
  - myko 3y ago
    It's likely `git reflog` would have their work, but not everyone knows about it
    - forrestthewoods 3y ago
Anticlockwise 3y ago
This site has developed a lot of content without seeming to directly address the major concerns anyone coming from git flow will have. For example, their code review page does not really address how github and gitlab are both set up to support branch based review, and trunk based review is a lot harder when using those tools. Similarly, I poked around and figured out what they recommend for hotfixes, which is just fix it on trunk and cherry-pick the commit. That works sometimes, but anywhere with infrequent releases (like regulated environments or shipped software) may find that pretty painful. I suspect I could raise more issues if I put more energy into it, but it's hard to want to, given how the content is presented. Overall, this site reads like someone who's so convinced they're right that they don't bother to take other viewpoints seriously enough to actually refute them.
- mixmastamyk 3y ago
  Maybe you missed this section? https://trunkbaseddevelopment.com/#scaled-trunk-based-development https://trunkbaseddevelopment.com/#scaled-trunk-based-develo... Trunk does not prohibit feature branches or code review.
revskill 3y ago
Confusing content without any clarifying step by step.

90 points by DLion 3y ago

Wait so no develop branch? The utility gained by having “what’s in production” and “what we’re working on” as separated feels hard to part with.

willsmith72 3y ago
if that's the only reason for the branch, you can just as easily determine which commit is on which environment with tags
- geraldwhen 3y ago
  Or put the sha in the version number.
- redcobra762 3y ago
  So if the “deployed branch” were really just a “tag”, that would fit trunk based development? Because that’s basically what git is doing. It’s not like there are two sets of files anywhere, afaik. My understanding of this though is that there isn’t supposed to be a difference between “what we’re working on” and “what’s deployed”, which I think then means you don’t really do “long term” development.
  - deleted 3y ago
    [deleted]
- ToJans 3y ago
  I've been working on my product for over 8 years, sometimes alone, sometimes with a tiny team. I have a mono-repo with one master branch - that auto-deploys to test - and one release branch that auto-deploys to staging. I can hot-swap my staging and production environment with the click of a button. Simple, and it allows us to deploy a hotfix of needed, and we've done some major work on master that needs to be validated first... But,... It all depends on your context and your needs...
  - willsmith72 3y ago
    the hotfix is extremely useful but you have to be so so careful when you're missing up history, when it comes to db migrations and api compatibility
  - andix 3y ago
    Sounds neat, but I still think complexity is removed if the deployment is not directly linked to the code repository. For me the code repositories purpose is to build software, and operation is not it's responsibility. I prefer having a gitops repository that describes the environment. Completely decoupled from the source code repository. If some automation directly from the source repository is required, a CI job can automatically update the gitops repository and trigger a deployment. Separation of concerns.
ec109685 3y ago
It’s still trunk based development even if a feature branch / tag is created that will match production.
- andix 3y ago
  I'm convinced that development and operation (deployment) should be thought of separately. The branching model for the code should only serve the purpose to create a working product (artifacts of some kind). Those artifacts should be versioned (can be semver, or just the short hash of the commit, or anything else). Once something is ready for deployment it can be deployed, in the best case this is just clicking one button or one CLI command. Developers shouldn't be afraid that one wrong commit can automatically just go to production.
fritzo 3y ago
I think the idea is that, rather than storing two versions of the code in your version control system, you store both versions in trunk and gate with a feature flag.
sowbug 3y ago
Your local repo is the equivalent of the development branch. Yes, that means you don't collaborate with others on development branches, or go for weeks committing only to a branch. If you save up a bunch of work, dump it on the main branch, then start a new development branch that lets you escape from the integration pain of your big merge, then trunk becomes a dumping ground that nobody wants to (or can) work on.
- edgyquant 3y ago
  Seems strange. Sometimes we’ll have feature branches that are made up of different parts, with different devs collaborating to build those parts out. For this I don’t see a way around having some staging branch with two devs sending PRs to before you work out all kinks and merge the staging branch back into main
  - jozzas 3y ago
    This is the hardest part about trunk based development - changing your way of thinking. Everything needs to be decomposed into much smaller changes, and you need to think about the impact of each of them being deployed into production (since that will happen). New features should exist behind some kind of feature gating or dial-up capability, or a new API version with restricted access, etc. That seems painful but it's less painful than merge hell or deploying a change with a massive delta to production and needing to roll it back and unpick what went wrong.
    - redcobra762 3y ago
      I dunno if I’m fully onboard, but anything that forces devs to think in terms of smaller changes will always get my attention.
  - sowbug 3y ago
    "before you work out all kinks and merge the staging branch back into main" Working out all kinks on an isolated branch is very hard to do. You need to integrate to hear the screams of the team you never expected your change would affect. So your choice is to integrate commit by commit on trunk, or to wad it all up into a single waterfall release from your branch to trunk, and then spend hours/days bisecting to find which commit caused the screams. As jozzas said, feature flags enable your code to safely lurk on trunk before it's functional.
andix 3y ago
If there are multiple environments it quickly gets impossible to keep track of "what's in production" as a branch. Two possible solutions: Git tag everything that's getting deployed. Or just keep track of the commit hash that is deployed.

tomoyoirl 3y ago

[flagged]

leetrout 3y ago
* Jenkins worker
- tomoyoirl 3y ago
  Maybe if they spun up a new cluster with new hostnames it’d say that. It doesn’t.
000ooo000 3y ago
Then you met with the Scrum Master to discuss planning?
- deleted 3y ago
  [deleted]
striking 3y ago
As of February 2016, references to "slave" in documentation began to be replaced with "agent": https://issues.jenkins.io/browse/JENKINS-27268 https://issues.jenkins.io/browse/JENKINS-27268 The comment I'd make is that this appears to have been settled nearly eight years ago in this particular context, and that maybe you should give it a rest.
- woooooo 3y ago
  It was "settled" in that we're all agreed it's obviously incredibly stupid but not worth fighting over and getting called racist. The good news is that "master vs mainline" was so embarrassing that even the people who push this stuff realized they overreached and have settled down since.
- tomoyoirl 3y ago
  You seem to misunderstand. My objections to the change are minimal. It is the incompleteness of the change that is remarkable.

Flux159 3y ago

I think that good tooling is a necessity to do trunk based development well - not just CI/CD and testing on PRs, but also being able to have stacks of commits in multiple PRs before landing as a whole (from ghstack, Sapling, or Graphite). Having worked at Facebook before where managing stacks of diffs was far better than GitHub, I wish that more of the improvements to the developer workflow could be open sourced beyond Sapling now that Phabricator is no longer supported.

lima 3y ago
Stacking with Gerrit works beautifully. Can only recommend giving it a try!
ramraj07 3y ago
Which of those three tools works best on GitHub? Ideally without paying (not that I mind paying but it’s impossible to get the approval for some niche tool like this)
- Flux159 3y ago
  I’ve used both Sapling cli & Graphite with github repos without having to pay anything. They both have extensions for vscode as well that makes it easier to manage stacks.
idlephysicist 3y ago
I agree with what you said but I'd further refine it by saying not just having testing and CI but actually having "high" test coverage and tests that actually test the code.

mlhpdx 3y ago

There is no “right” or “best” way to do this job, right? But kudos for taking a position and articulating it.

mgraczyk 3y ago

Google and Facebook both use trunk based development for nearly all code at both companies. This guide advises you to consider trunk based development if your release cycles are less than ~4 weeks. I'd suggest doing it no matter what. The only place where I've run into problems with this was managing very long term hold outs where we wanted to avoid changing user visible behavior. Instead of branches, we maintained literal copies of all the files for multiple years. I don't think revision control is the right place to solve that problem though, because there were no clear service boundaries to decide what things to pin, we just did it in an adhoc way.

ec109685 3y ago
How did the hold back end up working out? Was the learning worth the hassle?
- mgraczyk 3y ago
  Yes for sure. In some sense, I learned more from these holdouts than from anything else I've ever done in my career.
Scubabear68 3y ago
I am amazed at how much “process” developers these days have to adhere to, including complicated branching strategies plus a whole lot more. So much time wasted doing busy work. I have always been happiest in a trunk-based dev model, but in many orgs it is heresy to even mention it.
- dboreham 3y ago
  Imho this is an emergent property from the fact that most folks don't understand what they're doing. If they did, then every time Mr Dilbert pointy head dude comes up with some nonsense process, they'd explain why it isn't beneficial. Instead most of the time everyone nods. Lawyers don't have crazy people telling them how to write contracts. Doctors don't have people telling them how to saw off legs. Teachers kind of do have dumb people telling them how to teach though.

forrestthewoods 3y ago

I’ve been pretty happy with trunk-based development in my job. It’s simple and reliable. I don’t miss alternatives in any way. A significant amount of Git-isms are based around Linux kernel needs. Which is great. But closed source and typical open source needs are pretty different, and much simpler.

thaumaturgy 3y ago

Nice to see this getting some treatment. It's been my preferred source control strategy at several places now -- both small and large, though nothing so large as Facebook. It has its limitations, but for the the 90+% of places that aren't operating at Facebook scale, it's probably the right choice. It doesn't eliminate merge hell, but it does localize it, making it a lot easier to resolve conflicts without accidentally undoing somebody else's work. It's especially well-suited for any projects that are in constant-iteration mode, where there's a steady stream of bugfixes and new developments getting deployed daily (or even multiple times a day). You can even manage longer-lived branches after a fashion: the cleanest pattern seems to be to capture your changes into a patch, revert your branch to the commit immediately before your changes, merge/rebase main, then apply your patch on top. This is bad and lame because it rewrites history and requires a force push to get it into the remote, but it's also nice because it keeps your changes at the tip of the branch and makes review a bit easier in e.g. GitLab. Every small shop I've worked with that has tried to use more complex branching models eventually hoses the repo and ends up burning a lot of dev hours one day trying to make sense of a git log that looks like a diagram of network sorting.

reissbaker 3y ago
FWIW, Facebook also uses trunk-based development, so it works at that scale too!
striking 3y ago
A lot of the rebase/merge hell I've seen has been more or less resolved with the introduction of a merge queue. Granted, there are other issues that crop up (notably, flaky tests go from being an annoyance to life-threatening) but at least bigger changes don't get blocked and stay blocked.

yellowapple 3y ago

Seems very similar to Fossil's philosophy, which I've started to appreciate.

pard68 3y ago

I work at a place that has a few very large code bases, we use trunk-based. I will never go back, "what is your git workflow?" Is a question on my list of things to ask potential employers now and the only good answer is "trunk". So much mental load is wasted on these other strategies.

pylua 3y ago
It gets even worse — convoluted GitHub action templates that no one can debug, attempting to impose on every newly created repository. The projects at my company that use the complicated actions with gitflow are slower and less efficient. When I release a service at my company I just do trunk based ,but I have to redo the GitHub actions initially to save it from itself. Over the long run it saves me a lot of time.
giancarlostoro 3y ago
I'm not really sure what the mental load is but having gone to Trunk felt like a mistake, I don't know if it was just designed wrong at the last place I worked at, but we have to do more than normal per release, and I'm not a fan of squashing commits, it means I can't just go back to a branch and merge the development branch back into it, I have to check out a brand new branch. I also preferred having "master / main" and "development" because if QA claims there's a bug introduced during the development phase, you can figure out if it's already in the main production branch or if it truly was introduced during development. Which is something you can't really do with "trunk based development" it's like all these people who praise it should just switch to SVN instead?
- andix 3y ago
  I think you're mixing up a lot of things. Trunk-based development also doesn't mean that you are not allowed to create branches. And you can still check out an older version.
  - giancarlostoro 3y ago
    They deleted every branch on merge, and had us rebase for merges. Before trunk based development was introduced, everyone on the team understood what the flow was. Afterwards, whichever developer was picked to cut a release, took half a day to figure it out to make sure they didn't screw up. I would have rather just used SVN and called it a day.

gnabgib 3y ago

Could use a (2015) - according to the front-matter on the repo (in the master branch, natch). It's been posted here a number of times, it was particularly popular the first posted time in 2017[0] (199 points, 208 comments). [0]: https://news.ycombinator.com/item?id=13514289 https://news.ycombinator.com/item?id=13514289

TruthWillHurt 3y ago

It's the same fucking thing. You just painted each track different color and thickness. So people don't merge branches to main branch, but tag releases from it. ok. But they still need to merge their changes to main first, right? Same fucking thing, wrapped in execucrap.

danielvaughn 3y ago

We’re considering this at my org. We’ve got a distributed backend with about 2 dozen repos, with a big web of dependencies between them. When you need to make a breaking change to one that is depended on by a lot of the other repos, it can be incredibly tedious to fix all the downstream effects. Using trunk would resolve it, but would also of course introduce other issues.

golergka 3y ago
In my experience, just moving them all to one monorepo would already solve a lot.
andix 3y ago
Multi-repo software products maintained by the same team are another thing I'm probably never going to understand. In reality the components are never fully decoupled and nearly always released together. When splitting up a product into multiple repositories a lot of new problems are created. Every sub-project needs to be testable completely independently and then in a later stage integrated with the other components and tested again. With multi-repository it's much harder to isolate a change over multiple components into one PR and test those changes together. Instead they develop separately and after some time many of those changes are tested together. It's just making the feedback loop longer without any added value.
- codethief 3y ago
  > When splitting up a product into multiple repositories a lot of new problems are created. Every sub-project needs to be testable completely independently and then in a later stage integrated with the other components and tested again. While I'm a fan of monorepos, that issue doesn't completely disappear there, does it? I mean, if the monorepo contains the code for N artifacts (say, N, microservices that interact with one another), you will still have to make sure that the master version of microservice 1 plays nicely with the currently deployed version of microservice 2.
  - andix 3y ago

ChrisArchitect 3y ago

(2017) Some recent discussion: https://news.ycombinator.com/item?id=34733805 https://news.ycombinator.com/item?id=34733805

tripdout 3y ago

There's a workflow where you commit to each release branch? I genuinely did not know that. I thought working on individual branches, merging to master, and then cutting the release branch from there (to merge back into master if any changes were found during testing) was the only major way people actually did things.

c-hendricks 3y ago

I've been pushing and using trunk for years. To think someone looked at the graph for git-flow and said "yes please" is madness. That said, trunk-based is probably not great if you actually do need to support multiple versions of a piece of software simultaneously.

andix 3y ago
I'm not sure if any branching strategy helps supporting multiple software versions simultaneously. There is a reason why "rolling releases" are the default now. For a short while it may work to just merge bugfixes to older versions. But after a while the changes to older versions need to be done independently. Implementing a fix for three versions will just take three times longer than for one version very soon.

brirec 3y ago

TFA advocates strongly against long-lived branches, which I understand and agree with, but with one exception: major/LTS versions should have their own branch, so that hotfixes can be cherry-picked from main (or, rarely, applied directly to the major version branch.

sowbug 3y ago
That's right. It's important to be able to reproduce released builds with minor patches, and branches are the right tool for that job. But resist the temptation to fix that CVE on the release branch and then upstream it, because then you're once again doing branch development, treating trunk like a garbage can.

AdrianB1 3y ago

How does this look like when you have multiple active versions of an application? In some cases there are apps deployed in different environments (or to different clients) in different versions and having a single place to make all commits is not feasible. How do things that have LTS versions in parallel with "regular" versions organize?

andix 3y ago
How I've done it: Just tag the commit that is used to build a release. If you need to add a fix to an older release, create a branch from the tag. Do the changes trunk based on this branch, then tag and release. If needed just repeat it. I'm convinced that complex branching strategies never magically solve any issues. They just confuse many people until every successful release feels like dark magic.
- AdrianB1 3y ago
  Why not keep a permanent, separate branch for each version that is still maintained? And do trunk on each version branch.
  - andix 3y ago
    I don't like long lived branches. For me a branch is work in progress. Work should be finished, once finished the branch should be deleted. If you start work again, create a new branch. But sure, if supporting an older release is some kind of ongoing trunk-based process this is also a viable solution.

sonaj 3y ago

I like TBD. I've always found the difficulty was in getting people to use feature flags, and then also managing those flags. https://trunkbaseddevelopment.com/feature-flags/ https://trunkbaseddevelopment.com/feature-flags/

rplst8 3y ago

No thanks. I've worked on teams using trunk based development before and I ended up being the one having to fix other people's messes, deal with them losing work, and the absolute hell of trying to find where a bug was introduced. The only people I really want on my team are those that understand Git. And even when there are team members that don't understand Git, I sure do and can pretty easily un-eff any situation someone gets themselves into. Seriously, Git is actually simple and it should be a fundamental CS class taught at all universities.

rplst8 3y ago
P.S. sitting down and learning git was probably the single most useful activity I've done on my 23 year career as a dev.
sanderjd 3y ago
> the absolute hell of trying to find where a bug was introduced What does this have to do with a trunk based branching strategy? > Seriously, Git is actually simple and it should be a fundamental CS class taught at all universities. I'm fairly confused by this, as it doesn't seem to contradict OP, which is about using git...
forrestthewoods 3y ago
> deal with them losing work The fact that is ever possible is a damning indictment on Git > Git is actually simple The clearest evidence that something isn’t simple is when there are thousands of people yelling in frustration that it’s simple. Things that are actually simple don’t require a never ending stream of guides and tutorials. The world can do much, much better than Git.
- myko 3y ago
  It's likely `git reflog` would have their work, but not everyone knows about it
  - forrestthewoods 3y ago

Anticlockwise 3y ago

This site has developed a lot of content without seeming to directly address the major concerns anyone coming from git flow will have. For example, their code review page does not really address how github and gitlab are both set up to support branch based review, and trunk based review is a lot harder when using those tools. Similarly, I poked around and figured out what they recommend for hotfixes, which is just fix it on trunk and cherry-pick the commit. That works sometimes, but anywhere with infrequent releases (like regulated environments or shipped software) may find that pretty painful. I suspect I could raise more issues if I put more energy into it, but it's hard to want to, given how the content is presented. Overall, this site reads like someone who's so convinced they're right that they don't bother to take other viewpoints seriously enough to actually refute them.

mixmastamyk 3y ago
Maybe you missed this section? https://trunkbaseddevelopment.com/#scaled-trunk-based-development https://trunkbaseddevelopment.com/#scaled-trunk-based-develo... Trunk does not prohibit feature branches or code review.

revskill 3y ago

Confusing content without any clarifying step by step.