If you don't think of a commit message, you'll never be able to find this version again. If you think up a message every 2 minutes, you'll quickly find you spend more time thinking of commit messages than writing code.
I wish there was some kind of auto generated commit message. Things like:
"Added function xyz()" or "Adjusted constant FOO to 27" or "Made lots of changes in file a.c,, b.c and c.c".
These could be auto generated, and then commits could happen in the background every time the code is compiled.
It would be nice for git to have some kind of "commit of commits" which allows a hierarchical representation of commits. Ie. the "Add new printscreen feature" could have as subcommits "Create print renderer" and "Hook up print UI".
> "Added function xyz()" or "Adjusted constant FOO to 27" or "Made lots of changes in file a.c,, b.c and c.c".
I would argue that these are not good commit messages as they do not add information not already provided by the diff itself. Commit messages should communicate the intended effect of a change that has been made, rather than being a lossy compression of a sequence of keystrokes.
These are usually called feature branches.
> "Added function xyz()" or "Adjusted constant FOO to 27" or "Made lots of changes in file a.c,, b.c and c.c".
These are very poor commit messages that don't add anything of value; any diff viewer will tell you the same immediately, so you might as well leave it blank.
> Commiting frequently also has a substantial cost of needing to think of a commit message.
In larger, private feature branches I'll use loads of "asdf" commits that I will later squash together. These are my "ok, so far so good" points to make figuring out where I broke something easier.
You can edit the history later when it's required by somebody else working on the code.
Or you can just not care. 99% of the value of your git repo should be in the most recent commit.
- Stub in [classes/models/etc] for checkout flow
- Add basic test coverage
- Fix my API for easier testing
- Decouple foo from bar in new flow
- New checkout flow mostly tested
- New flow UI cleanup and add comments
- Fix nasty [N+1/O(n^2)/etc] performance bug in new flow
- New flow feedback from acceptance testing
- New flow ready to merge
- [And often enough/honestly] "WIP to share with..." or just
"WIP" for work in progress, "Fixing bug in" or whatever reality there was.
“Added unit tests and stub out api” (50 files) vs “fix bug when files are added too quickly” (1 file, 3 lines)
I typically have it open beside my IDE so I can keep an eye on the progress in the file tree view. I can drag-select a set of lines, right-click and stage them, when I'm basically locking those in, then keep going.
It also auto-fetches every minute or so, so I have great visibility on what coworkers are doing in the commit graph. Lets me react to what they do pretty quickly, and I can implicitly review what they do and I can poke them if I notice something weird.
FWIW, I also sometimes work this way; however I delete the commented out block when I'm finished. This is also a pet peeve of mine, the only time commented out blocks of code are acceptable is if the obvious way to write something introduces a bug or ignores an edge case. In that case, I also leave a note explaining not to refactor this section and explain why.
But especially while refactoring or fixing certain issues, I really find it helpful to have the prior version still present to compare against. If I have to commit while that commented code is still present, invariably my last commit message is along the lines of "removed commented code" or "cleaned comments for function XYZ". Especially since for these cases I also typically end up writing a comment once finished anyway. If there was something tricky enough happening that I was comparing against older code, likely there is something confusing enough happening that whoever is in the file next could also use some additional explanation that can only really be written once finished.