DEV Community

Cover image for The Message is the Bug
Nowshin Alam Owishi
Nowshin Alam Owishi

Posted on • Edited on

The Message is the Bug

#programming #git #github #softwaredevelopment

Git isn't something we study every day, yet we use it daily. Most of the time, we cycle through the same handful of commands, such as fetch, add, commit, and rebase, like muscle memory. It's ironic how something so essential remains so frustratingly complex.

I'll be writing about some of the lessons I've learned from Git. To make things more readable, I'll be writing in separate blogs. I hope that it will help you avoid the disasters I once walked straight into.

Let's start.

Lazy Messages Can Come Back to Wreck You

  1. Using git blame
    • You are in a hurry, office time ends in 2 minutes, you wanna commit with messages like "asdf" or "fixed bug", thinking you’ll finish it after the weekend, why spend so much time thinking about it?
    • But somehow that weekend passes, and fast-forwarding two months later, you re-opened that project at 2 AM, or a teammate inherits your code. Suddenly, git blame points to "asdf" and the author has your name. Now everyone hates you, including yourself.
  2. Using git bisect
    • Suppose the production failed, and you need to know which commit failed. You are using git bisect and find out that a commit with 55 file changes, and a commit message as "fixes", has caused the issue.
    • Now, good luck first finding what the fixes were, then finding the one that introduced the bug.
    • A good, well-written commit message may let you skip the first one. You would already know what the changes were and focus on finding the bug.

What Went Wrong?

You wrote commit messages for yourself, not for:

  • The developer who joins next year
  • Your sleep-deprived future self
  • The debugger team
  • Or any other person who wants to read and review your code

What Should You Do Then?

  1. Think of what you have done: Find out the core and crucial changes in your commit. Have multiple fixes in a single commit? Write with comments.
  2. Think of the audience: Write messages so that anyone engaged in that project can decode them in 10 seconds.

Here are some examples of proper commit messages.

# Commit message 1 (with comments)- 
fix(auth): resolve critical security issues

- Handle null case in session timeout logic
- Fix authentication bypass in dashboard

# Commit message 2
feat(ui): implement dark mode toggle [WIP]
Enter fullscreen mode Exit fullscreen mode

Write What Matters

  1. Clarity beats rules, everything else is secondary. The first and foremost thing in a commit message is that it should be understandable. The 50/72 rule won't be helpful if the commit message is ambiguous.
  2. Aim for precision first, add description when the impact or fix isn’t obvious. Long commit messages are often a symptom that maybe your commit includes too many unrelated changes. Each commit should ideally represent a single logical unit of work, and its message should reflect that.

You can find resources online on how to write proper commit messages. You'll get incredible guides on commit messages online; the internet has perfected this art far better than I could summarize here.

How to Add a New Commit Message

Single-line Commit Message 

git commit -m "Add login validation"

# Or

git commit --message="Add login validation"
Enter fullscreen mode Exit fullscreen mode

Multi-line Commit Message 

git commit -m "Add login validation" -m "Added frontend and backend validation for login" -m "Closes #123"
Enter fullscreen mode Exit fullscreen mode

Editor-based Commit Message 

git commit
Enter fullscreen mode Exit fullscreen mode

An editor will open, and write your commit there. However, you will have an advantage here. If you wanna break down your commit message into bullet points, leave an empty line after the subject, then start each line with a - for better readability (just like markdown).

fix: handle session timeouts

- added null check for expired tokens # bullet point 1
- ensured redirect to login page # bullet point 2
Enter fullscreen mode Exit fullscreen mode

You can view your commit history, including the commit message, using git log.

How to Alter Previous Commit Messages

Change the Latest Commit Message 

git commit --amend
Enter fullscreen mode Exit fullscreen mode

This opens your editor. Update the message, then save and close.

Change an Older Commit Message

You will need to use interactive rebase for this.

git rebase -i HEAD~3 # 3 is the position of the commit relative to the HEAD
# Or
git rebase -i abcd1234^ #abcd1234 is the hash of the commit that you wanna change
Enter fullscreen mode Exit fullscreen mode

This will open a list of the last 3 commits in your default editor:

pick abcd1234 message you wanna change
pick aswd1235 other commit
pick iucd2234 other commit
Enter fullscreen mode Exit fullscreen mode

Change pick to reword (or r) for the commit you want to edit:

reword abcd1234 message you wanna change
pick aswd1235 other commit
pick iucd2234 other commit
Enter fullscreen mode Exit fullscreen mode

Then save & close.

Git will open another editor window where you can change the message. Modify and save again, and you're done!

⚠️ Heads-up

git amend and git rebase rewrite history; they change the commit hash. If you’re editing an older commit (not the latest), rebase will also modify the hashes of all commits that come after it. Be careful when force-pushing, especially on shared branches, you might overwrite others' work.

I chose this simplest yet crucial topic to give a good start to the series. Meet you in the next part with a more complicated topic - cherry-pick 🍒!

Top comments (0)