4 ms·
My recent preferred workflow is to automate commits for docs + commits inside feature branches with a tool I wrote (https://github.com/nikitavoloboev/gitupdate
by nikivi 6y ago
My recent preferred workflow is to automate commits for docs + commits inside feature branches with a tool I wrote (https://github.com/nikitavoloboev/gitupdate https://github.com/nikitavoloboev/gitupdate). It creates commits with the files changed as commit messages.
The branches ideally gets squashed with proper commit message when merging so git history is clean. And no time is wasted writing commit messages that often say whatever the code should already say.
- explodingcamera 6y agoThis seems like a really bad idea. Even a 2 word commit message would be better for someone who is trying to review your code, all git hosting websites include files changed anyways and it's trival to use the cli to check for that.
- naavis 6y agoIn my experience commit messages shouldn't describe what was changed, they should describe why the change was made.
- nikivi 6y agothat is why you shouldn't waste time writing commit messages for where this not much to `why` something has changed. (i.e. docs, refactors..)
- bithaze 6y agoIt's really not that much time though. "templates" and ".github" are examples of such vague commit messages that they _require_ looking at the commit to understand what changed. With a short, descriptive commit message, you can just glance through the commit log.