Consultant, Full Stack Dev, Game addict. Tech Lead @ MOBIKO. Loving Nodejs, Typescript and Vue. Interested in Clean Code, agile methods and Software Engineering
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
"current status"
"b4 refactoring xy"
"Added another test"
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.
Consultant, Full Stack Dev, Game addict. Tech Lead @ MOBIKO. Loving Nodejs, Typescript and Vue. Interested in Clean Code, agile methods and Software Engineering
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.