The evolution goes on. Now that we’ve kind of sorted out most of our infrastructure, development tools, flows and processes, I guess, it’s time to look deeper into the things we’ve had for a while and reiterate over them.
Recently, I’m seeing a lot of blog posts on articles on how to write good commit messages. Sure, we’ve had these for a while. But lately things get a little bit more serious.
Here’s one (in Russian) that I’ve read recently. Here’s another one (in English) that shares some of the concepts and suggestions.
What are they saying? Well, “write better commit messages”, obviously. But there are a couple of specific bits which I found interesting. They are:
Conventional Commits – a specification for adding human and machine readable meaning to commit messages.
Commitizen (git cz) – a tool that help to write conventional commits.
For the skeptics among you, I slightly share your feeling. It does seem like a bit too much overhead. But as someone who works with an ever-growing team on a large number of projects, I think there is a place for it. It’ll take a while to integrate, update the process, and enforce the discipline, but I think it’s well worth it. At the very least, it deserves a try.
While I understand it a lot better now, I still much prefer the merge approach. It’s simpler and less dangerous, and maintains the full history. This might get noisy at times, but works as a last resort when trying to understand what was going through the developer’s head when he was working on a piece of code.
sr.ht – pronounced “sir hat” – is a new competitor in the world of GitHub, BitBucket, and GitLab. Much like all of these, you can either self-hosted it or use a managed service. It might not yet be as fancy, polished, and cool (I think they need a better name and the domain) as its competitors, but there are a couple of reasons that might make a difference when making a choice:
Open Source. From a quick look, sr.ht is distributed under the GNU Afero GPL.
Modular. The suite consists of the following components:
git – git repository hosting service
build – continuous integration service
lists – mailing lists service
todo – ticketing system / bug tracker
dispatch – task dispatcher and integration service
Hacker News points to this Linux kernel patch, done by a 4-year old. With some assistance, of course, but still impressive. And while the story is cute, the comments are even better. In particular, a link to this email from Linus Torvalds, talking about the importance of the small and trivial contributions.
To me, the biggest thing with small patches is not necessarily the patch itself. I think that much more important than the patch is the fact that people get used to the notion that they can change the kernel – not just on an intellectual level (“I understand that the GPL means that I have the right to change my kernel”), but on a more practical level (“Hey, I did that small change”).