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.
I had the same reaction. Particularly on every commit being independent. Seems like a lot of work that will mostly be wasted.
I guess if your work approach is exceptionally chaotic, it makes sense. But I don’t think I would ever have the time to be as chaotic as the author seems indicate they are.
I like to rewrite history so every feature has a test commit followed by a implementation commit. Then I can easily run the test to see it fail, move the head up a commit, and run it again to see it pass.
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.