Precisely. In practice, trunk based development just means your branch is local instead of on remote.
What do you mean by local? git can hide merges or feature branches, and you have to save your temporary code by pushing it to the server at the end of the day. You can rebase your code or squash it before merging, but TBD is not talking about that IIRC.
If the work I'm doing is on a feature branch on remote or locally, why does it matter to the rest of the team? My integration steps can be done on a server instead of locally. TBD forces teams to collaborate synchronously since changes are pushed straight to trunk. Rebase or squashes are irrelevant here.
Another poster put it great: TBD is trying to solve a culture problem. Feature branches and pull requests into main is much more flexible. The only time TBD make sense is for small teams - like 2 or maybe 3. And even at 2, I'd much rather create feature branches that merge into main.
TBD forces teams to collaborate synchronously since changes are pushed straight to trunk
The main page about TBD says you can still use feature branches, merge requests, or squash/rebase, and that's how I use it. It only says why and how you should use release branches, and how you should fix bugs in a release. The linked article is not talking about TBD at all, hence my confusion about this whole post.
Precisely. In practice, trunk based development just means your branch is local instead of on remote.
What do you mean by local? git can hide merges or feature branches, and you have to save your temporary code by pushing it to the server at the end of the day. You can rebase your code or squash it before merging, but TBD is not talking about that IIRC.
If the work I'm doing is on a feature branch on remote or locally, why does it matter to the rest of the team? My integration steps can be done on a server instead of locally. TBD forces teams to collaborate synchronously since changes are pushed straight to trunk. Rebase or squashes are irrelevant here.
Another poster put it great: TBD is trying to solve a culture problem. Feature branches and pull requests into main is much more flexible. The only time TBD make sense is for small teams - like 2 or maybe 3. And even at 2, I'd much rather create feature branches that merge into main.
The main page about TBD says you can still use feature branches, merge requests, or squash/rebase, and that's how I use it. It only says why and how you should use release branches, and how you should fix bugs in a release. The linked article is not talking about TBD at all, hence my confusion about this whole post.