71–80 of 185 posts
This post describes a widespread standard practice. People never complain about my commit messages and they don't have trouble understanding them.
I prefer Github's method of "git commit messages don't matter, pull requests do". Nowadays, you can easily enforce that the ultimate commit log looks rather nice by doing this: 1. Make it so the only merge strategy allowed on a repo is "Squash and Merge", so each PR = 1 commit in main branch 2. Have engineers care about the pull request quality rather than commit messages It's easier to be more expressive in a pull r…
For the code review step, sure, commit messages don't really matter unless your team reviews PRs commit-by-commit. How many times do you actually change the default squashed message? If you write a series of garbage commit messages, I don't particularly trust that you'll write a very good squashed message, either. How many times do people skip updating the PR description with new information or features from comments…
Earlier quoted context omitted.
Conversely I hate these with abundance. If you feel that working on your project is a chore, why are you still working on it?
I don’t particularly enjoy cleaning my house but I love the aftermath. Same with bumping versions on dependencies. If I didn’t have to do it I’d love to just get the new features in a non-breaking way. But I can’t, so I do, and it’s a chore.
Earlier quoted context omitted.
> Having whitespace-altering "Dummy commit to trigger CI, ugh!" `git commit --allow-empty` may be sufficient for that "there is a new commit" trigger in many cases. If so, that may be preferable to whitespace changes as those clutter up the blame. As an aside, my initial commit on a repo is an empty one so that I can branch from a completely empty repo to do radical rewrites and yet maintain a history relationship wi…
> As an aside, my initial commit on a repo is an empty one so that I can branch from a completely empty repo to do radical rewrites and yet maintain a history relationship with that initial empty commit (which I feel is preferable to an orphan branch and then a merge with unrelated histories ... though those tell slightly different stories in the log). Oh cool, I thought I was literally the only person on the planet…
Earlier quoted context omitted.
Conversely I hate these with abundance. If you feel that working on your project is a chore, why are you still working on it?
It doesn't literally mean chore. It means a code change that you do regularly but is not major, and usually doesn't require much work (update dependencies being a good example). > Chore: A routine or minor duty or task Rather than > Chore: An unpleasant or burdensome task
So "update". Attaching emotionally charged words like "chore" does nobody any favors, and in fact has negative consequences.
I like the conventional commit style [0]. You may have seen these in open source repos or used them at work. They look like feat: support new line chart fix: update props for new line chart chore: bump dependency version What's also cool is there are tools (semantic release) that will then handle automatically the versioning and publishing of your module based on these commits using the commit type (feat, fix, chore…
Conversely I hate these with abundance. If you feel that working on your project is a chore, why are you still working on it?
I hate that rule about 50 characters. IIRC, it started because someone noticed that the average commit message in the linux kernel is about 50 characters. Then, for whatever reason it morphed into this widely propagated mantra saying that the maximum should be 50 characters.
Earlier quoted context omitted.
I've been using github-changelog-generator [1] for (you guessed it) automatic changelog generation, which adds bug fixes/features to the changelog based on issues and PRs, but sematic-release looks like it might be even more useful. [1] https://github.com/github-changelog-generator/github-changel...
These "changelog generators" look to me like barking at the wrong tree, automation for the sake of automation, and attempt to skip the "boring" work of communicating changes by replacing it with "interesting" work of massaging git history, inventing microformats, etc. Why bother with separate changelogs at all then when you can see changes in `git log`. Just write good commit messages! /s
Earlier quoted context omitted.
Conversely I hate these with abundance. If you feel that working on your project is a chore, why are you still working on it?
It doesn't literally mean chore. It means a code change that you do regularly but is not major, and usually doesn't require much work (update dependencies being a good example). > Chore: A routine or minor duty or task Rather than > Chore: An unpleasant or burdensome task
Marking it as a simple chore sounds like the impact has not been fully analyzed.
I understand the practice and if done meticulously by all contributors, it should at least signal a well organized project but most of the time, it just shovels your entire commit log as a release notes. It's OK to have it, but I much prefer projects that takes time to summarize the impacts to their users.