> The author is not arguing against making small, logical commits. He's arguing against making a ton of changes in your working directory, then running `git add file1, file2... ; git commit` a bunch of times in a row to record a series of commits.
> The problem with this is exactly the one he mentioned: almost no one ever goes back and makes sure each commit actually builds and passes tests.
Right. For git, IMO the right way to do this is:
$ git add -p # stage the first bunch of changes you want to commit
$ git stash save -k # push all the unstaged changes to the stash
$ # build your code, run tests, whatever
$ # repeat until it builds clean
$ git commit # record the clean (possibly fixed) commit
$ git stash pop # get your other original changes back
Repeat as needed until all your stuff is committed. If you can't make a subset of your changes build clean, then it's not independent and should not be committed standalone.
Comments
> The author is not arguing against making small, logical commits. He's arguing against making a ton of changes in your working directory, then running `git add file1, file2... ; git commit` a bunch of times in a row to record a series of commits. > The problem with this is exactly the one he mentioned: almost no one ever goes back and makes sure each commit actually builds and passes tests.
Right. For git, IMO the right way to do this is:
Repeat as needed until all your stuff is committed. If you can't make a subset of your changes build clean, then it's not independent and should not be committed standalone.