> 1. It's a communication mechanism. Other people on your team should know what approaches you're exploring.
If they have the time to do that, they can look at a branch as well.
> 2. It is much easier to review small, incremental PRs than a massive PR dumped at the end of a project.
It's also much easier to entirely lose track of what the purpose of a feature was if you only review it in small, incremental chunks. The chunks often make sense individually, but are a convoluted mess when you look at the full picture. Also, a feature branch should still have many small commits on it, and you can easily review those individually as well, but you also get to look at the whole picture before putting everything in. Not to mention, if it needs to be reverted, much much much easier if there's a single PR with 50 commits instead of 50 disparate commits over 3 weeks.
> 3. The lift from merge conflicts / integration work is less.
If you pull everyday from the main branch, there's rarely a problem with merge conflicts and integration work, unless someone else is doing a major refactor. And if they are, there is going to be a problem regardless of whether you commit early or late, you'll still have to keep adjusting to their ongoing refactor (and the possibility of ever reverting will be slim to none).
> And why do you think it's somehow better to have code behind a runtime branch (if) rather than a git branch?
1. It's a communication mechanism. Other people on your team should know what approaches you're exploring.
2. It is much easier to review small, incremental PRs than a massive PR dumped at the end of a project.
3. The lift from merge conflicts / integration work is less.