As I progress through the IBM Full-Stack JavaScript Developer track, the complexity of my projects is ramping up. Early on, version control was just a way to save my work. I would type git commit -m "fixed stuff" and move on. But as I prepare for real-world engineering roles, I am learning that a professional GitHub presence requires more than just making your repositories public. It requires writing commits that other humans can actually read.

There is a whole layer of Git conventions that tutorials rarely teach, but enterprise engineering teams enforce religiously. Here are the unspoken rules of version control that instantly separate junior codebases from senior ones:

  • The Imperative Mood (Active Voice): Have you ever wondered why standard Git messages are written as "Fix bug" instead of "Fixed bug" or "Fixing bug"? It is because Git commit messages are designed to complete a specific sentence: "If applied, this commit will [your message here]." Writing "If applied, this commit will fixed bug" makes no sense. The imperative mood treats commits as instructions for what the code will do, rather than a diary entry of what you did.
  • The 50/72 Rule: A professional commit message has a strict formatting limit. The subject line should be 50 characters or less, forcing you to be concise. If you need to explain why the change was made, you leave a blank line and write a body paragraph wrapped at 72 characters. This ensures the logs remain highly readable in terminal windows.
  • Conventional Commits: Enterprise teams use strict prefixes to categorize their work. A commit should never just say "Updated header." It should say feat: add user profile dropdown or fix: resolve mobile overflow issue. Using prefixes like feat: (new feature), fix: (bug fix), chore: (maintenance), and refactor: (code restructuring) allows teams to automatically generate changelogs and trace system regressions instantly.
  • Atomic Commits: A commit should only do one thing. If you fix a database schema and update a CSS button in the same commit, rolling back the broken database will also delete the button fix. Commits must be logical, isolated units of work.

During a recent DevCareer session, we discussed the importance of building a highly professional GitHub footprint, right down to generating well-structured README files for every project. Clean commit history is the next step in that professional visibility.

What is the worst Git commit message you have ever written or encountered in a shared codebase?