[thih9]

Why write meaningful commit messages at all then? Should we perhaps “git commit -m foo” all the time and call it a day?

My experience here varies wildly; I’ve worked on projects where commit history was carefully maintained and documented, as well as on projects with random squashing or random commit messages. Both had their own benefits and came with a cost too.

For larger, more complex or more mature projects, going through git history can be a common task. So here I’d prefer meaningful commit messages; git blame/bisect/etc gets easier, and sometimes any additional piece of docs has immense value. For smaller, simpler projects or prototypes, where history isn’t used that often, I don’t care that much.

[claytongulick]

Not proud of it, but honestly > 50% of my commit messages are "wip" or similar.

Source backup is one of my primary uses for SCC, and when I step out for lunch, or need to knock off for the day, I commit where I am, and push with a "wip" (work in progress) message.

The feature branch name I merge is probably the most useful. It's an aggregate of all my commits and what I'm working on.

[alisonatwork]

I do this too, but when I come back from lunch I git reset HEAD~1 and keep going till I have a meaningful piece of work to commit on its own. You can also use interactive rebase to reorder or squash commits if you realize that for readability reasons it makes more sense for a refactoring you started later to appear earlier in the stack or for a subpar commit and its subsequent fixup to be combined. This makes the final history more easy to read for reviewers, and (after it's merged) more easy to read for future you and other devs on the project too.

[freedomben]

interactive rebase is (IMHO) the golden ticket for this. Unfortunately, if you're using git as a backup then that means you pushed the commits, so a `git push -f` will be required. I do that all the time and think in general we are unnecessarily scared of it. As long as you're the only person working on the branch, a push -f is NBD. Never do it to master though or a shared branch unless you plan to bring donuts or something in later as an apology.

[ycombobreaker]

Yeah where I work, we strongly encourage interactive rebase on solo feature branches.

In fact, even the hairiest long-lived branches can get cherry-picked apart into several "layers" of branches to get reviewed and merged piecemeal. It's really easy if you're starting from too many commits. It gets harder (not impossible) if individual commits commingle said layers.