[yoz-y]

Depends on your workflow of course. Having all commits on master always pass tests (and thus requiring to rebase the merged branches so their individual commits pass) has advantages (such as this easy bisect).

You would still be able to commit and push to your feature branch without breaking the CI. I guess it would be possible to enforce the rules on feature branches but that would be counter productive IMO.

[krzyk]

OK, but if you commit on feature branches then those commits will land also on master (squashing is not something popular and makes frequent commits pointless).

Frequent commits (without making sure they pass tests) allow better git blame/annotate (figuring out why given line of code was added, and having a general comment "introduce feature ABC" is not helpful, but having a message "add field to to something" is).

You can't make detailed commit messages if you have large changes.

But yeah, everything depends on the workflow one commits to.

[yoz-y]

When I worked with git I squashed/reordered my feature branch to make it pass tests on every commit before merging it with the master. This is usually not very hard and you can still do small commits. You can even split new tests into a separate commit.

Honestly I don’t really see why would you want to change code that breaks tests without updating them in the same commit. Updates in tests give strong signal to the PR reviewer to see that an API has changed. When fixing bugs it’s also nice to be able to reproduce it with a test case first, then fix it.