I don’t understand the argument against applying linting and static analysis to every commit on every branch. It’s one thing to check in work that’s unfinished in the sense that the unit of work’s requirements or acceptance criteria haven’t been met, but I don’t see the value in checking in a change that results in a broken build.
First, I’d suggest that waiting for commit time is too late, at least for linting. In many cases, the linter can be integrated with the editor or IDE, giving real-time feedback on many potential problems. For anything that isn’t automatically correctable, this will make it readily apparent to the developer that something needs to be corrected. Perhaps it’s OK to correct it later and make a commit into a feature branch with some unresolved linter warnings, but the number can be reduced with the editor integration.
The idea of checking in “half-finished” code is somewhat worrying, as well. What, exactly, does “half-finished” mean? If the code is introducing something that will break the build, like compiler errors or syntax errors that will cause unhandled exceptions at runtime (in interpreted languages), I can’t think of a situation where that would be acceptable. Even if the change is incomplete, the application should not be in a broken state. The use of keystone interfaces and feature flags can also help to hide unfinished work if some changes need to be integrated upstream.