It depends on the project being worked on. If the main branch changes often enough that you need to merge master before you merge the branch you’ll spend a lot of time propagating changes.
And then there’s the problem of large codebases. Without a really good cache strategy for builds all of the branch switching and merging will cause a lot of rebuilds. For some languages and large projects that can be 20+ minutes for a fresh build on each switch. That’s enough time to get distracted by emails or hacker news.
I’m a big fan of small commits, often and breaking down changes but it does require a large amount of automation and tooling to support well.
One nice feature of git-branchless (I'm the author) is in-memory rebases. For example, the `git sync` command will rebase all local work on top of the main branch without checking out those branches. (It will also not start merge conflict resolution unless you pass `--merge`, which makes it a lot "safer" to frequently rebase your work.) This helps a lot to avoid invalidating builds.
And then there’s the problem of large codebases. Without a really good cache strategy for builds all of the branch switching and merging will cause a lot of rebuilds. For some languages and large projects that can be 20+ minutes for a fresh build on each switch. That’s enough time to get distracted by emails or hacker news.
I’m a big fan of small commits, often and breaking down changes but it does require a large amount of automation and tooling to support well.