2. and 2a. say that commits MUST be independent, and MUST come with tests. Then 3. comes and it turns out nothing is a must.

2b. is something to debate on. I prefer to use git branches as a work stage tracker. Commit last known good state, off to the races on the next batch. So, it’s okay to push something with broken tests on a branch as long as tests work when merging to main. Then again, this argument sorta kinda holds if one works with squash commits. Nobody should care what’s on the branch and how many commits in what state are there. My branch is my scratch pad. The state matters during the merge of a pull request.

1. is also interesting. A branch must do one useful thing. Can it do more than one?

All in all, those rules are too taxing for my liking.