over 5 years ago Syntax Podcast
Hasty Treat - Writing Good Commit Messages
- 00:26 Conventional commits
- 00:50 Conventional commits help commit messages
- 01:02 Sentry tracks errors by commit
- 02:16 Wes hasn't used conventional commits
- 04:04 Commit message syntax
- 05:01 Remembering syntax is hard
- 05:43 CLI could help with commits
- 06:49 VS Code extension helps
- 07:49 SemVer explained
- 09:03 Versioning with conventional commits
- 09:46 Automatic npm versioning
- 11:38 Awesome documentation
VS Code extension helps
Scott Tolinski
So I did this, that, whatever, and it's gonna create your commits for you. And to me, that is such a better way to do this than me trying to remember the actual syntax for conventional commits. I think this to me was the biggest barrier for this because I would look at this. And let me tell you,
Scott Tolinski
tent it says tense description, but maybe it means terse.
Scott Tolinski
the
Scott Tolinski
It asks if you what kind of emoji you wanna give this? Oh, that's great. This Versus code one asks you if you want the lipstick emoji or the rocket ship emoji. Okay? Then write a short,
Scott Tolinski
The documentation Overwhelming. If I look at this, I can look at it, and I would say, oh, wow. There's a lot to to learn here. But Yeah. If you install one of these CLIs or tools, hey. That that's all of the, the the The hard stuff out of the way for me. Let's talk about SemVer real quickly. So SemVer is you know, when you see, like, a node package and you see, like, 1.5, conventional commits, Wes. Is this something you are currently using?
Sentry tracks errors by commit
Wes Bos
No. It's it's not. Like, we mentioned a couple episodes ago that, like, colon or refactor colon, and I I'm like, oh, that's cool. But then I see it over and over. I'm like, There must be something that people are following, and I found it. It's conventional commits. And this is really interesting to me because,
Scott Tolinski
To our code in century or specific versions. You can see which version and what kind of commits went into this code. And it's so nice that you'll be able to track all of this and say, hey. Remember that thing that you did? There was an error there. And then in your commit message, you can,
Scott Tolinski
And, again, one of the cool things here is that when we're dealing with conventional commits, right, we can attach That to me seems like I'm gonna have a lot of trouble
Scott Tolinski
that allows you to track all of the exceptions and errors in your location. In fact, you'll wanna check out century at century.i0.
Scott Tolinski
because you can get what commit, what version everything happens to if you connect your a. Based on the tags that are in these commits. Yeah. You know what? I'm really interested in that because if you were to look in the level of tutorials, GitHub issues right now, you would see one that says Automatic versioning, and then the body of the issue says, I'm really tired of having to change the version myself.
Scott Tolinski
And then you're referencing that issue in your conventional commit. A lot of cool stuff here. So let's get into and a system for The sort of specific commit messages that you can write that can then have more intent and functionality within your application
Scott Tolinski
Have a better idea of the bug that it fixed or anything like that that you're attaching because maybe you're creating an issue automatically in GitHub in Sentry,
Scott Tolinski
Repo to century at century.i0, which is our favorite error and exception handling tool
Scott Tolinski
actually Commit messages are hard, and having a system for it takes all the guesswork out of it. So we're gonna be talking about conventional commits in this episode. My name is Scott Talinski, I am a developer from Denver, Colorado. And with me as always is Wes Boss.
Automatic npm versioning
Scott Tolinski
gee, just the amount of tools and and features around this stuff really gives you a good idea of why you should use it, And I think people should take notice about just how neat some of this documentation is. It feels like you know those, like, awesome GitHub repos where it could be, like, awesome conventional commits? This to me feels like Yeah. That repo as the documentation. I wonder if that is a thing.
Scott Tolinski
is just how Awesome. This documentation is because they do everything in, like the body of it's in, like, a big FAQ, essentially. I mean, besides the the introductory stuff, It it teaches you the spec, whatever. But then there's a whole FAQ. And then below that, there's some resources for about, tooling for conventional commits of which there is a lot. You can always tell when something is highly used by how much tooling there is around it. And then project using conventional commit, so you can check out some people who are using it and see what it looks like in action. And to me, this is like gold star documentation. I really love this. I Hey. Hey, Wes. You know one place where conventional Well, commits will definitely come in handy is your Sentry for conventional commits, yeah, it's pretty easy to parse. But if you look at this page, it can specifically be a little bit that are saying, oh, hey, dude. What it what type of release is this? What does this do? Whatever.
Scott Tolinski
Yeah. Right.
Wes Bos
I've got a couple packages on npm, and every single time that I have a a change to 1, I have to, like, bump it myself, like Scott just said, and publish it myself. And Automating that would be would be really slick. Be really slick. And, also, it would it would go really well with just everything else in my workflow, especially like we mentioned in Sentry because You can, you know, attach errors to versions. Right? Whenever
Scott Tolinski
I get an error in my Sentry, it tells me what version of the software it's on. And if This is all done automatically, Use the coupon code tasty treat, all lowercase, all one word for 2 months for free.
Scott Tolinski
Yes.
Scott Tolinski
and we could have version updates, micro versions much more often when I'm not like, every commit or whatever Orvie, Ivery, whatever. It's really gonna nail that in just a little bit more, and I think that sounds fantastic. One thing I do wanna shout out here in this conventional commits.org Yeah. That's what it is. Yes. You nailed it. You should register that domain. Yeah. So neither of us Wes and I haven't Haven't necessarily started using this yet, but we're both gonna give it a a good try. Right? And I think we may we should do a check-in and and talk a little bit about what we've learned about conventional commits Over time.
SemVer explained
Wes Bos
You might be wondering, like, look. What are those numbers?
Wes Bos
as an example. That 0.2 was released because they released 1.5.1 1.5.0,
Wes Bos
Which is patch releases, the the very end of it. There's feature, which is adding new stuff. That's the middle. And then you have breaking changes, which is The main one. So you can you can associate these and and probably even generate your SemVer version for your package
Wes Bos
December is broken down into the 3 major Oh, yeah. We're late to the game on this, Scott. Late to the game on this, but
Wes Bos
you have fix,
Wes Bos
conventional commits because a, yes, it does give you much better history as to what happen, but what I was surprised to find out is there's lots of tooling around
Wes Bos
but they added some new functionality You can have an optional body, which describes it a little bit more, and then you have optional footers, Which is often used for custom stuff. Like, if you want to if you run Jira and you wanna link it back to a Jira tag,
Wes Bos
Finally, the the one point, the very first one is breaking changes. So let's say they release something that totally broke how a method on the API worked, Then they bump it to 2.0 to 0. And this is kind of associated with test, perf, Alright. I think that's it. Scott and I are gonna try it, and maybe we will I don't know. Maybe 6 months from now, we'll do a follow-up show to see how we liked it, when we didn't like it, and if it made any of our our workflow and lives easier. Yeah. I am very excited to do this, and I'm I'm on board. I'm a 100% on board.
Wes Bos
and then they realized something was broken. So they fixed it and released a dot release, which is that. The 1.5 pretty look. Pretty good. I can use them. Sometimes we put garbage ones in there. I don't I don't put And that's fine because Speak for yourself. Because you can squash them all into into 1 commit. But I've been seeing a lot of poll requests come in lately with something like Build colon or fix colon or chore
Transcript
Announcer
Open wide dev fans. Get ready to stuff your face with JavaScript, CSS, node modules, barbecue tips, git workflows, breakdancing,
Announcer
Tolinski.
Announcer
soft skill, web development, the hastiest, the craziest, the tastiest TS, web development treats coming in hot. Here is Wes, Barracuda,
Announcer
Boss, and Scott, El Toro Loco,
Announcer
Monday. Monday. Monday.
Conventional commits
Scott Tolinski
Welcome to Syntax. In this Monday, hasty treat, we're gonna be talking all about conventional So There's not. It's because the docs are an awesome list already. Whenever I learn anything, like, the first thing I do, awesome blank. I mean, I'm I'm doing a lot of Deno right now, so I was doing awesome dino, and then you get all the awesome stuff right there. It's almost like it's in the name.
Scott Tolinski
commits.
Scott Tolinski
And if that sounds like something you never heard of before, then you are gonna be very excited about this one because this is gonna be talking about commit messages
Scott Tolinski
overall.
Wes hasn't used conventional commits
Wes Bos
They also
Wes Bos
that actually happens. So so what is it? Well, Every time you have a commit, in your commit message, you will write the type of commit. That can be fix, feature,
Wes Bos
colon, and then you write a description of of what you changed. And then there is In optional so commit messages can be multiline.
Wes Bos
parsing these commits and helping you decide what to release or what changed. And That's really interesting because,
Wes Bos
breaking change, build, Chore, refactor,
Wes Bos
like, I've been working with the folks on Keystone lately, and every time that they put in a commit,
Wes Bos
commit a dot change file, and it will describe what changed. And then when they do a release, they're able to just automatically compile all of those What changed? And they have all these like, you know, you you look at the the change releases as to what happened. I was like, oh, that's how people are generating these things. They're automatically doing it. They're not just someone Been like, what did we do since the last Writing him a bunch of Yeah. Right. You know? On on what specific commits do those changes happen? Yeah. I thought that was really cool, And I'm assuming that's what Versus Code does as well because every time Versus Code releases, they will link back to a commit 0.2? Beautiful. Alright. Well, thanks so much for tuning in. We will Catch you on Wednesday.
CLI could help with commits
Scott Tolinski
let me tell you, I also installed the the conventional commits GitHub extension or I'm not the GitHub. The Versus Code extension. And so you use standard command shift p conventional commits, and then it gives you a drop down saying, what Type is this? Is this a feature? Is this a bug? Whatever. And then it asks you for the scope. Alright? And I could say no scope, no scope 360.
Scott Tolinski
But I did all This is what I want. This is what you want. And there's also another one. It's c z c l I, which is also a conventional commit CLI, which looks like it has quite a bit of people used to 10,200.
Remembering syntax is hard
Wes Bos
that Prompts you for each of the pieces. There's a Versus code extension I saw. And when you do a commit, it will prompt you for each of these 1, 4, or 5 different pieces of information. Yeah. I f. Actually, it's funny you mentioned that because I had just Googled conventional commits CLI to try to find the same thing, and I found, 3 major parts. There's fixes, which is our So let's look at 1.5.2 part, The the 0.5 is they were on 1.4, to it, but they didn't break Anything else. So that they went from 1.4 to 1.5 because now there is this new method that you can you can go ahead and use.
Scott Tolinski
keeping track of all of the details here. Is this something that you're concerned about in your own? Like, I I know I have, like, I have memory issues where I'm gonna forget all of the the structure of this kind of thing. In fact, when I think about BEM, I have to, like, go through my brain. Alright. Block. Like, what is the order that they all go in for for BEM? Yeah. So, like, for people who have a hard time remembering, like, really specific orders and stuff Like that, do you do you think is that gonna be something that you're gonna have a a trouble with, or you're just gonna pipe this into your brain and leave it there? I think I think you'll you'll get to to know it because It's like Git committing and things like that, but, like, I think I'm also thinking now, like, could there be some sort of, like, CLI I I think that it is
Awesome documentation
Scott Tolinski
Head on over to syntax.fm I really think that this could be actually something that Could help us out in that regard. I'm I'm really excited to give this a try. I know we are definitely late on the boat to this one. The bolt pulled up and left, and now we're, like, trying to we're saying, wait. Hold on. We're gonna miss the boat. Looks like there is a already a package that will, Based on the commits, we'll generate a semantic version for you and automatically publish to that. If you go to the bottom of this conventional commits .org.
Scott Tolinski
for a Full archive of all of our shows. And don't forget to subscribe in your podcast player or drop a review if you like this show.
Wes Bos
Peace. Peace.
Versioning with conventional commits
Wes Bos
There's tooling for conventional commits. There is one that's just called semantic versioning, And, subsequently,
Commit message syntax
Scott Tolinski
So you mentioned that there's a specific format in a body potential footer.
Scott Tolinski
for writing commits.
Scott Tolinski
it's a convention specific commits Either way, it write a description.
Scott Tolinski
Is that
Wes Bos
for code changes that is also readable. I would say it's a a conventional