Search for a command to run...
Your future self will thank you.
i'm trav
i've also been known to make music
I completely agree with these points Travis Aaron Wagner. Good commit messages can save a developer a lot of time trying to figure out what has changed and where.
Great article!
I love how you took my article and basically made it better :D Thanks for sharing your thought on git commits. It's a topic I think we don't talk about enough. And this leads to junior git users not getting into a good git habit.
I've always been intrigued by browser extensions and their ability to do crazy things and make the web cooler + get rid of ads. That said, going from concept to a working Chrome extension can be super annoying with repetitive setup tasks, configurati...
This is going to be a "quick" little guide to customizing the tmux status bar to include a scrolling Spotify “Now Playing” widget. I’m going to be doing this on macOS, but you should be able to adapt it to Linux and I'll try to assist where I can. If...
Go From Freelancer to Corporate Sellout In 43 Easy Steps
An overview of one of the most popular and loved programming languages.
The Importance of Mental Health as a Developer
I recently read a helpful article on Hashnode by Simon Egersand titled "Write Git Commit Messages Your Colleagues Will Love," and it inspired me to dive a little deeper into understanding what makes a Git commit good or bad.
You're probably thinking to yourself, "my commits are just fine, thank you." But are they really? Let's take a closer look.
Git commits are like little snapshots of your code. They let you and others see what changes were made, and when. They also let you roll back those changes when something inevitably goes wrong.
That's why it's important to make sure your git commits are as clear and concise as possible. Otherwise, you run the risk of confusing yourself and others down the road.
There are three main problems I find with many commits:
These commits are essentially worthless. You know the ones I'm talking about - they just say "updated" or "fixed bug" or something similarly unhelpful.
It doesn't have to be that way. Let's look at why these kinds of commits are a problem, and what you can do about it.
They don't tell us anything about what was actually changed. Was a bug fixed? Was a feature added? We have no idea.
It makes it harder to analyze when we're trying to find out when a particular change was introduced. If a commit just says "updated", we have no way of knowing whether it introduced the change we're looking for or not.
It's lazy. If you can't be bothered to write a decent commit message, then why are you making it in the first place?
So, what can you do about it? Simple: make sure your git commits are informative. Tell us what was changed, why it was changed, and how it was changed. Use subject line wisely, and include extra information in the body. Otherwise, developers (including your future self) might just end up ignoring your commits altogether.
Your git commits should be helpful to others who may be working on the same codebase. That means including information that will help them understand the changes you made, and why.
Here's the problem: when you make a git commit, you're only required to provide a brief message describing the change. But that's not enough information for other developers to understand what you did and why.
As a result, many git commits are cryptic and unhelpful. The classic "updated libraries" doesn't actually tell us anything about the change that was made.
This is a problem because it makes it difficult for other developers to understand the history of a project. It also makes it hard to figure out who to blame when something goes wrong.
And we need to know who's to blame.
Your git commits should be concise and to the point. You want them to be informative, sure, but one wants to read a novel every time they look at the commit history. I personally have a problem writing commits that are way too long, and often have more files than I should in one commit.
I know, I know, I should be making small, atomic commits that are easy to revert if something goes wrong. But sometimes, I just can't help myself. I make a change, and it's so big and complex that I just have to commit it all at once. And then I have to go through the process of squashing all those changes into a single commit.
It's a pain, and it often leads to messy, hard-to-read commit histories. But worst of all, it can make it really difficult to revert a change if something goes wrong.
So, please, for the sake of your sanity and the sanity of those who have to work with your code, try to avoid making these long commits with multiple files. Stick to the small, atomic changes that are easy to revert.
Your future self will thank you.
Now that we know what makes a bad Git commit, let's look at how to make your commits better.
Your git commits should be clear and concise. That means including a proper description of what changed, and—more importantly—why it changed.
Try to put yourself in another developer's shoes and ask yourself if what you wrote would be helpful to others who may be working on the same codebase. That means including information that will help them understand the changes you made and again, why.
There's a trend here.
As I mentioned before, your git commits should be direct and to the point. Be sure to remove any unnecessary information from your commit messages, and split them up where it makes sense. Longer doesn't always mean better; keep the subject line short and move other details to the body. Smaller, atomic commits are much easier to understand and can be rolled back without affecting other working code.
Here are some examples of good commit messages:
Remove unused CSS
Get rid of unused selectors from primary stylesheet to drastically reduce load time.
Update README
Add a new section on how to run tests to provide more information to developers.
Fix bug in login flow
Add a new redirect which takes users to the home page if they're already logged in, preventing users from getting stuck.
Writing quality Git commits is a crucial part of building a successfully project and collaborating with other developers. Your messages should be clear, concise, and helpful to others. By following these tips, hopefully you can make sure your commits are all of those things.
If you want to take it a step further, you could follow the Conventional Commits specification.
Let me know in the comments if this was helpful or if you have any questions.
Be sure to follow me for more like this!