I will often paste a line from the CHANGELOG.md into the commit.

We used to use Perforce, which forced you to write a commit message. One of my employees used to write "asdf". It got a bit old. I didn't care that much, myself, as he was responsible for maintaining his own code, and he did fine, there.

The Japanese hated it, though, and it probably played a big part in his getting laid off. I learned a big lesson, there, and insisted on my employees being more circumspect, after that.

I think there are two things in tension here. VC is primarily useful to help make sure you don't lose work and can merge separate threads of work into one place. In distant second is its ability to communicate those changes being made. That's also probably happening on numerous other places, like your issue tracker, documentation, whatever. Anyway, if I'm in the middle of something that doesn't really form a complete coherent change but also represents work I don't want to lose... You might get useless commit messages.

Useful commit messages are valuable, but so is the ability to actually incrementally change and back up your code. As an aside, that's why I think blocking pushes to remote due to failing tests/linter issues/basically any reason is misguided.

> but so is the ability to actually incrementally change and back up your code

Backing up the code is why I will end up with multiple WIP commits when working on a large change. I want to get it pushed to the remote to not risk losing large amounts of work if something happens to my local copy. It's also nice knowing that if an emergency or something keeps me away from work for some time, the work I was doing could be picked up by a coworker without needing to convince InfoSec to provide them access to poke around the drive of my PC.

That's exactly what makes distributed version control systems so powerful. Your local WIP commits, even when pushed out to a remote backup branch, have generally nothing to do with what you push out for others to review and integrate into working branch. Working this way with systems like Subversion would be much harder, if not impossible.

Yes, that makes a lot of sense. I like to have many small commits, as opposed to one big one.

However, I’ll often defer a commit, to avoid “breaking the build.”

I’ve come to avoid branching, if at all possible, using tags, instead.

That works for me, as I generally work alone, but it does not work for a team. In that case, we need working branches, and a stable mainline.

In my experience, commit comments are almost worthless, except as “mnemonics.” I tend to use diff views, instead, to figure out commits.

It's simply disrespectful to not use the tools thats main purpose is to inform others of what's going on. I've seen it before and I don't fuss about it, but it's so arrogant, like "_I_ know what's up, and that's all that matters. Hmph".

Write good commit messages. Use present tense like "Add cats to news feed.". For your "WIP", squash them together once there's something cohesive.

Next on my gripe: A single half sentence email responses!