I'm a creature of habit. I tend to configure things the way I like them, lock that in, and hunker down into the little ecosystem I've made for myse...
For further actions, you may consider blocking this person and/or reporting abuse
Don't worry too much about your commit message while you work and commit often. Finish up your work and rebase --interactive to put your work and messages together.
I do suggest breaking commits for unrelated things so they can be grouped when rebase is run.
Eh, I disagree. It helps me a lot because it makes me try to tackle one problem at a time. Without it I can easily go off the rails. And as a lead developer, I'm trying to set good examples for others on my team who currently have commits that say things like "fix it" and "make it better." I'd rather work that way from the start than be met with a complex rebasing after the fact 😊
I just found this answer and also support Jesse Philips way. I feel your argument of being lead developer and setting good examples, but one good example for me is trying to be much more productive than my colleagues.
If you care too much about commit messages in the first place, you'll end up spending time on details that don't matter at all (or even worse: start thinking about wether you should commit now or not. Spoiler: The answer is always yes ;-) ).
Maybe we use a different strategies, but I tend to commit like at least 10 times+ an hour. There are some commits like
and so on. The commit messages don't matter, as long as I know where to go back if something goes terribly wrong.
That way I don't spent much time on thinking about fancy commit messages, don't lose much work if I somewhen really need to take a step back (6 Minutes or something? Whatever...) and can take some time for the "nice" commit message when the actual PR will be transmitted.
I do think that committing too frequently can be a problem. Vim is my version control before I make a stamp, but it only does one file.
What is the downside of commiting too frequently in your opinion?
When a change is "trivially small" (a rarity), leaving just a commit title without additional detail works just as well of course. Adding the extra detail on somewhat larger commits helps me understand what I just did by recapping, and may also help another developer spelunking in the commit history someday. In terms of productivity I don't find myself spending a great deal of time on it...it's just jotting notes :)
Too mutch shuffling between different attempts could lead to difficulty in navigation the different attempts.
I reference vim because, like emacs, it has undo trees. Vim has a decent concept of an edit. If I extrapolate vims edits to commits I would find the history to be invaluable.
Git commit --fixup HEAD~3
Git commit --fixup ":/less wonky"
thoughtbot.com/blog/autosquashing-...
Git is a Communication tool
Jesse Phillips