3 ms·

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: ht

by 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.
      - jrochkind1 3y ago
        Makes sense, matches with my experience. For those who mean this by "trunk-based development" -- and I'm not sure everyone in this thread, including OP, does -- I think it would be clearer to just say "avoid long-running branches", instead of calling that a new method "trunk-based development". But either way, yeah, what you say matches my experience and the consensus on best practice in communities/teams I have worked on already. I didn't really realize this was not universal, is perhaps my confusion! But I am still not sure if simply avoiding long-running branches is what OP was describing!

by eterm 3y ago

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.
    - jrochkind1 3y ago
      Makes sense, matches with my experience. For those who mean this by "trunk-based development" -- and I'm not sure everyone in this thread, including OP, does -- I think it would be clearer to just say "avoid long-running branches", instead of calling that a new method "trunk-based development". But either way, yeah, what you say matches my experience and the consensus on best practice in communities/teams I have worked on already. I didn't really realize this was not universal, is perhaps my confusion! But I am still not sure if simply avoiding long-running branches is what OP was describing!