A recent post on Hacker News highlighted the benefits of detailed commit messages in git.
Usually, my git commits look something like this:
> git commit -m "fix: component missing configuration file"
…which isn’t all that helpful. (Related: see XKCD on git commit messages)
I decided to try and utilize this newfound knowledge in my own git commits and I quickly ran into an obstacle. Simply using
> git commit opens up vim. Which, I really don’t want to use. (I’m sorry!)
This is something I should already know how to do, but I had to do a Google search to learn more. It turns out, you can change the default editor in git. This makes it much more convenient! How do you do it?
git config --global core.editor "nano"
Replace “nano” with your preferred editor of choice. Now, running
> git commit opens up your editor and you can make detailed commit messages to your heart’s content!
I’m always searching for better ways to improve my workflow, increase productivity, and just generally learn new and exciting things. (Besides, it’s part of having a healthy growth mindset.)
We’ve had some big changes on our team during the past year and I’ve felt like I’ve needed to step up when it comes to reviewing code that my fellow colleagues write. While searching for some ideas on how to improve my code review skills, I discovered a blog post from 2018, entitled “Code Review from the Command Line“.
This blew my mind and really helped reframe how we engineers should approach code reviews:
When I ask that other people review my code, it’s an opportunity for me to teach them about the change I’ve just made. When I review someone else’s code, it’s to learn something from them.
Jake, the author of the above post, goes on to describe his setup and custom tooling for conducting an interactive code review.
He uses custom git alias to see which files have changed and how many changes there are, a custom script that visualizes how often the files within the pull request have changed over time, and another custom script that can visualize the relationship between changed files.
All of these go above and beyond the call of duty for reviewing code, but it’s stuff that decreases friction and can make a sometimes tedious process much more enjoyable.
I’ll be implementing some of these ideas into my own workflow in the near future.