8 ms·
Honestly, the best guidance is just "put more than 2 seconds effort into your commits". No one really believes "More code" is a good commit message, it's just l
by Traster 4y ago
Honestly, the best guidance is just "put more than 2 seconds effort into your commits". No one really believes "More code" is a good commit message, it's just laziness. So yeah, put a little effort in, it's literally one of the few parts of your work that will remain once you are gone. Most code I've worked on gets replaced/updated/modified after I'm done working on it - but the one thing that I know will stay is the git history that some poor bastard will have to search through to figure out why this random bit of code ended up this way.
The only other thing I'll say is don't be weird. I knew a guy who would prepend his commits with a [tag] saying what part of the repo his commit was touching. This was a mixed sw/hw project and every single commit of his started with [sw]. It's like, ok thanks, firstly, you're a software engineer working the ../sw/ folder, secondly no one was confused that your 17 changes to a C++ file were going to be a hardware change.
- mmcnl 4y agoI like this. Any advice other than "putting in effort for more than 2 seconds" has a lot of hidden assumptions about the context and organization around your code. Some days I only do a commit once at the end of the day as a backup. Other days I have 10 commits in 1 hour because everytime I thought I was finished I found something else that needed to addressed. In practice, there often is not a very strict process around commits, so specific advice is often not very useful either.