> 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.
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.
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
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.
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).