3 ms·

> It always contains 100% of everyone elses code. It contains no one else's code since everyone works on a branch. This is only holds if a single team uses a b

> It always contains 100% of everyone elses code. It contains no one else's code since everyone works on a branch. This is only holds if a single team uses a brach. That doesn't scale.

dspillett 3y ago
> It contains no one else's code since everyone works on a branch. 100% of everyone else's code that has made it to main. If you need to coordinate more closely (i.e. different people working on related changes, which is likely to be common) then the branch doesn't have to be local and just for you, it can be shared, perhaps with individuals having their own local copy of that for quick check-ins¹ without publishing to others until ready². Whether this scales manageably will depend on the project and your team dynamics. -- [1] to save work state before experimental changes, or just to have an off-machine last-known-good copy (assuming your “local” repo is covered by off-machine backups or is not actually local) [2] though this indirection adds extra overhead – someone needs to rebase that from main then everyone may need to rebase to bring local copies in line
- mannykannot 3y ago
  I feel it is likely to scale better than the alternatives, as it is a recursively hierarchical model of a recursively hierarchical problem. It would break if people are committing broken things, but then you have a different and more fundamental problem.
mlyle 3y ago
No one commits as they write each line of code. There's always code in flux and you are not integrating with everyone else every minute. Branches vs. on-trunk misses the mark, IMO: the question is what's your practices like for how frequently changes get integrated. There's multiple dimensions of freedom in how you do things. Branching is a nice tool to have. Avoiding long-lived feature branches is best (particularly with a big subset of the team working in them). (But, dang, sometimes you need these abilities, too, so having a workflow that supports them well is good).
alkonaut 3y ago
It contains 100% of everyone’s finished code and 0% of their unfinished code. Whether the amount of unfinished code is 1 hours worth or 1 weeks worth isn’t very interesting to me. It doesn’t matter if Bob was on holiday or if he has done 4/5 days of his big change. I just want a stable main. The amount of in progress work acceptable will differ if you work on a 20 year old desktop app with quarterly realeases like me vs a startup with 6 weeks of runway left.

> It always contains 100% of everyone elses code. It contains no one else's code since everyone works on a branch. This is only holds if a single team uses a brach. That doesn't scale.

dspillett 3y ago

> It contains no one else's code since everyone works on a branch. 100% of everyone else's code that has made it to main. If you need to coordinate more closely (i.e. different people working on related changes, which is likely to be common) then the branch doesn't have to be local and just for you, it can be shared, perhaps with individuals having their own local copy of that for quick check-ins¹ without publishing to others until ready². Whether this scales manageably will depend on the project and your team dynamics. -- [1] to save work state before experimental changes, or just to have an off-machine last-known-good copy (assuming your “local” repo is covered by off-machine backups or is not actually local) [2] though this indirection adds extra overhead – someone needs to rebase that from main then everyone may need to rebase to bring local copies in line

mannykannot 3y ago
I feel it is likely to scale better than the alternatives, as it is a recursively hierarchical model of a recursively hierarchical problem. It would break if people are committing broken things, but then you have a different and more fundamental problem.

mlyle 3y ago

No one commits as they write each line of code. There's always code in flux and you are not integrating with everyone else every minute. Branches vs. on-trunk misses the mark, IMO: the question is what's your practices like for how frequently changes get integrated. There's multiple dimensions of freedom in how you do things. Branching is a nice tool to have. Avoiding long-lived feature branches is best (particularly with a big subset of the team working in them). (But, dang, sometimes you need these abilities, too, so having a workflow that supports them well is good).

alkonaut 3y ago

It contains 100% of everyone’s finished code and 0% of their unfinished code. Whether the amount of unfinished code is 1 hours worth or 1 weeks worth isn’t very interesting to me. It doesn’t matter if Bob was on holiday or if he has done 4/5 days of his big change. I just want a stable main. The amount of in progress work acceptable will differ if you work on a 20 year old desktop app with quarterly realeases like me vs a startup with 6 weeks of runway left.