6 ms·

I think the article paints a false dichotomy. DVCSs and trunk-oriented development are fully compatible. I work on an open-source project using git that has bo

I think the article paints a false dichotomy. DVCSs and trunk-oriented development are fully compatible. I work on an open-source project using git that has both a main branch that's continuously-deployed, and stable branches for twice-yearly community releases. We treat the main as a trunk: everyone makes small PRs to it and they're generally deployed day-of, if not within a couple of hours. If anyone's PR is too big, they're generally asked to split it up for incremental review+merge into main. PRs are generally rebased onto to main and tested via CI regularly, including right before merge. So, we enjoy all the "trunk-based" development benefits that the article describes. I get the impression that this workflow is common in the industry, especially for GitHub users. That said, the branching features of git are still essential for us for creating, testing, and patching those stable community release branches. That's not to mention the offline development quality-of-life features that DVCSs give us. I couldn't imagine not using a DVCS!

chippiewill 3y ago
> everyone makes small PRs to it I don't think that's the trunk based development that they're advocating for. I believe the version they're advocating for is where all developers commit and push changes directly to the main branch.
- goodoldneon 3y ago
  How would code review work if everyone is committing and pushing? The article must mean tiny, short-lived branches
  - kdmccormick 3y ago
    "Pair programming", maybe? Anyway, agreed. Particularly, I wonder how any significant refactoring is approached.
    - jdlshore 3y ago
      Refactoring is easier with short-lived (minutes to a few hours) branches, because refactoring causes branches to diverge over time. Significant refactoring, done correctly, is a series of small refactorings, and they can be integrated every 30-60 min to minimize impact of changes.
  - claytongulick 3y ago
    With trunk based, code review happens as a sort of forcing function every time you do a pull and merge it in. You see what everyone has done and how it affects you before you can push. (I'm not advocating for this, but I've worked in this style and it has pros and cons).
- kdmccormick 3y ago
  Yeah, you're right. I just think that what the article argues for is a just a worse version of trunk-oriented git usage. Every benefit the article names is available via git, but git also gets me a place to share and automatically test my changes (which might be a simple but risky refactoring) without literally editing the trunk. If there is a benefit to true trunk-based development over just trunk-oriented DVCSs usage, the article did not describe it.
eterm 3y ago
That's trunk based development as I understand it and how I enjoy it. Short lived feature branches that are merged back into trunk as soon as they are reasonably stable. Deployment cadence is orthogonal, but CI ensures that it could be deployed at any point, even if it wouldn't or shouldn't be. User acceptance testing and QA is done on the deployed main, and stable release candidates are branched from a point in main. This might just sound like "branch based development" to many, but the key difference is that the feature branches are designed to only live within the context of a single sprint, for days or possibly hours, meaning there isn't time for "merge hell" to fully develop. Good hygeine merging trunk into feature branches has a similar effect of course, which is why with good VCS hygeine there isn't that much difference.
- jrochkind1 3y ago
  Ah, short-lived feature branches is what I assume is everyone's default way of working these days, and assumed best practice. Maybe I had a distorted view of that. But I was thinking OP meant something different, literally no feature branches. But maybe I misunderstood? I think OP would benefit from more description of the actual process they are talking about, how you carry it out, what it looks like day to day, instead of just a list of benefits of a process it assumes you understand. I'm not sure we're all talking about the same things.
  - eterm 3y ago
    OP might well be talking about that, but it doesn't match what some close to authoritative sources would understand as "trunk based development": Atlassian: https://www.atlassian.com/continuous-delivery/continuous-integration/trunk-based-development https://www.atlassian.com/continuous-delivery/continuous-int... trunkbaseddevelopment.com: https://trunkbaseddevelopment.com/ https://trunkbaseddevelopment.com/ Both of which describe having short lived branches. Atlassian is more aggressive with their timescale of "short lived", suggesting they should be closed out daily. This contrasts with the "gitflow" model of development with long lived feature branches, which can live across multiple sprints. It also doesn't make sense in a git based world, because there isn't much difference in concept or outcome between local and not-yet-pushed commits to local main vs a local branch. The local branch just has a nice description and makes it slightly easier to organise the merge back to remote main later. In both cases, you'd have the same (if any) merge conflicts, ultimately you have a situation where you need to merge, say, local commit 81f0f61e1 into remote shared history commit efe3c586c and, say, remote (latest) commit d224e5b7b. In both cases I'd recommend merging remote main into the branch / local main to get a single commit on your local main/branch with both shared histories so there's no conflicts. IF there are conflicts trying to do that, resolve it with a local merge commit and manual conflict resolution. That you happen to name your local commit at the point of divergence is a convenience for more easily controlling when to merge commits, and to enable switching back to a shared history more convenient. (git switch main is easier to remember than git checkout <hash>). If OP is claiming to "not have branches" then they still do have a logical equivalent to branches, just without some of the tooling that branches make quicker. Edit: Edited to avoid suggesting what "most" people think, because that is hard to judge.

chippiewill 3y ago

> everyone makes small PRs to it I don't think that's the trunk based development that they're advocating for. I believe the version they're advocating for is where all developers commit and push changes directly to the main branch.

goodoldneon 3y ago
How would code review work if everyone is committing and pushing? The article must mean tiny, short-lived branches
- kdmccormick 3y ago
  "Pair programming", maybe? Anyway, agreed. Particularly, I wonder how any significant refactoring is approached.
  - jdlshore 3y ago
    Refactoring is easier with short-lived (minutes to a few hours) branches, because refactoring causes branches to diverge over time. Significant refactoring, done correctly, is a series of small refactorings, and they can be integrated every 30-60 min to minimize impact of changes.
- claytongulick 3y ago
  With trunk based, code review happens as a sort of forcing function every time you do a pull and merge it in. You see what everyone has done and how it affects you before you can push. (I'm not advocating for this, but I've worked in this style and it has pros and cons).
kdmccormick 3y ago
Yeah, you're right. I just think that what the article argues for is a just a worse version of trunk-oriented git usage. Every benefit the article names is available via git, but git also gets me a place to share and automatically test my changes (which might be a simple but risky refactoring) without literally editing the trunk. If there is a benefit to true trunk-based development over just trunk-oriented DVCSs usage, the article did not describe it.

eterm 3y ago

That's trunk based development as I understand it and how I enjoy it. Short lived feature branches that are merged back into trunk as soon as they are reasonably stable. Deployment cadence is orthogonal, but CI ensures that it could be deployed at any point, even if it wouldn't or shouldn't be. User acceptance testing and QA is done on the deployed main, and stable release candidates are branched from a point in main. This might just sound like "branch based development" to many, but the key difference is that the feature branches are designed to only live within the context of a single sprint, for days or possibly hours, meaning there isn't time for "merge hell" to fully develop. Good hygeine merging trunk into feature branches has a similar effect of course, which is why with good VCS hygeine there isn't that much difference.

jrochkind1 3y ago
Ah, short-lived feature branches is what I assume is everyone's default way of working these days, and assumed best practice. Maybe I had a distorted view of that. But I was thinking OP meant something different, literally no feature branches. But maybe I misunderstood? I think OP would benefit from more description of the actual process they are talking about, how you carry it out, what it looks like day to day, instead of just a list of benefits of a process it assumes you understand. I'm not sure we're all talking about the same things.
- eterm 3y ago
  OP might well be talking about that, but it doesn't match what some close to authoritative sources would understand as "trunk based development": Atlassian: https://www.atlassian.com/continuous-delivery/continuous-integration/trunk-based-development https://www.atlassian.com/continuous-delivery/continuous-int... trunkbaseddevelopment.com: https://trunkbaseddevelopment.com/ https://trunkbaseddevelopment.com/ Both of which describe having short lived branches. Atlassian is more aggressive with their timescale of "short lived", suggesting they should be closed out daily. This contrasts with the "gitflow" model of development with long lived feature branches, which can live across multiple sprints. It also doesn't make sense in a git based world, because there isn't much difference in concept or outcome between local and not-yet-pushed commits to local main vs a local branch. The local branch just has a nice description and makes it slightly easier to organise the merge back to remote main later. In both cases, you'd have the same (if any) merge conflicts, ultimately you have a situation where you need to merge, say, local commit 81f0f61e1 into remote shared history commit efe3c586c and, say, remote (latest) commit d224e5b7b. In both cases I'd recommend merging remote main into the branch / local main to get a single commit on your local main/branch with both shared histories so there's no conflicts. IF there are conflicts trying to do that, resolve it with a local merge commit and manual conflict resolution. That you happen to name your local commit at the point of divergence is a convenience for more easily controlling when to merge commits, and to enable switching back to a shared history more convenient. (git switch main is easier to remember than git checkout <hash>). If OP is claiming to "not have branches" then they still do have a logical equivalent to branches, just without some of the tooling that branches make quicker. Edit: Edited to avoid suggesting what "most" people think, because that is hard to judge.