3 ms·

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 reasonab

by 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.
  - jrochkind1 3y ago
    Do you always only have one local commit on your branch, though? Or is that irrelevant?
    - eterm 3y ago
      In git, no you do not: PS C:\Users\eterm\Documents\code\aoc\adventclient> git rev-parse HEAD a2e0c38327569533f2fc704bfe9617473011bf11 PS C:\Users\eterm\Documents\code\aoc\adventclient> git checkout -b test-branch Switched to a new branch 'test-branch' PS C:\Users\eterm\Documents\code\aoc\adventclient> git rev-parse HEAD a2e0c38327569533f2fc704bfe9617473011bf11 PS C:\Users\eterm\Documents\code\aoc\adventclient> git status On branch test-branch nothing to commit, working tree clean Both HEAD of main and HEAD of the branch point to the same commit until there is another commit.
      - jrochkind1 3y ago
        Right, I know how git works. I meant in the method of work you are describing, but it sounds like the answer is you don't consider the number of local commits that differ from main branch to be constrained by what you are calling "trunk-based development", it's fine to have several. Is what you are calling trunk-based development simply avoiding long-lived branches?
        eterm 3y ago
        I think "number of commits" varies too much between different developers to be a meaningful comparison, I've seen some developers commit every time their code actually compiles, and other developers not commit until they're ready to push to main / remote branch. But yes, trunk based development is about avoiding long lived branches, reducing the pain of merges. Others think there is a contradiction there, that if they regularly merge from main to their long lived branches then they are avoiding merge hell, but they're not, because you can have the following situation: 1. Person A keeps long lived branch, "Feature X including refactor Frob" 2. Person B keeps long lived branch, "Refactor Y including Frob changes" 3. Person C makes regular commits to main. Persons A and B regularly merge the changes from main, thinking they are avoiding merge conflicts, and on a literal sense they are, but what will happen is that when they realise they have incompatible changes, there will be an incentive for them to rush their feature branch into main first, so that they don't feel responsible for sorting the merge conflicts that will happen. There will be a perverse incentive to dodge quality because they don't want the other side to get their branch in before them. Also, because both branches A and B are long-running, their incompatibility and conflicting nature can be hidden for a long time.
UK-Al05 3y ago
That's still way way slower integration points then trunk based. When i was doing trunk based dev we were integrating every few minutes to hours.

by eterm 3y ago

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.
- jrochkind1 3y ago
  Do you always only have one local commit on your branch, though? Or is that irrelevant?
  - eterm 3y ago
    In git, no you do not: PS C:\Users\eterm\Documents\code\aoc\adventclient> git rev-parse HEAD a2e0c38327569533f2fc704bfe9617473011bf11 PS C:\Users\eterm\Documents\code\aoc\adventclient> git checkout -b test-branch Switched to a new branch 'test-branch' PS C:\Users\eterm\Documents\code\aoc\adventclient> git rev-parse HEAD a2e0c38327569533f2fc704bfe9617473011bf11 PS C:\Users\eterm\Documents\code\aoc\adventclient> git status On branch test-branch nothing to commit, working tree clean Both HEAD of main and HEAD of the branch point to the same commit until there is another commit.
    - jrochkind1 3y ago
      Right, I know how git works. I meant in the method of work you are describing, but it sounds like the answer is you don't consider the number of local commits that differ from main branch to be constrained by what you are calling "trunk-based development", it's fine to have several. Is what you are calling trunk-based development simply avoiding long-lived branches?
      - eterm 3y ago
        I think "number of commits" varies too much between different developers to be a meaningful comparison, I've seen some developers commit every time their code actually compiles, and other developers not commit until they're ready to push to main / remote branch. But yes, trunk based development is about avoiding long lived branches, reducing the pain of merges. Others think there is a contradiction there, that if they regularly merge from main to their long lived branches then they are avoiding merge hell, but they're not, because you can have the following situation: 1. Person A keeps long lived branch, "Feature X including refactor Frob" 2. Person B keeps long lived branch, "Refactor Y including Frob changes" 3. Person C makes regular commits to main. Persons A and B regularly merge the changes from main, thinking they are avoiding merge conflicts, and on a literal sense they are, but what will happen is that when they realise they have incompatible changes, there will be an incentive for them to rush their feature branch into main first, so that they don't feel responsible for sorting the merge conflicts that will happen. There will be a perverse incentive to dodge quality because they don't want the other side to get their branch in before them. Also, because both branches A and B are long-running, their incompatibility and conflicting nature can be hidden for a long time.

UK-Al05 3y ago

That's still way way slower integration points then trunk based. When i was doing trunk based dev we were integrating every few minutes to hours.