4 ms·

In git, no you do not: PS C:\Users\eterm\Documents\code\aoc\adventclient> git rev-parse HEAD a2e0c38327569533f2fc704bfe9617473011bf11 PS C:\Users

by 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

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!