Top 5 Git Commit Message Best Practises in 2024

When you join a project as a new developer, you see one thing above all: no standards for Git commit messages. Some put emojis in the message, others write in the present tense, others in the past tense. But which top 5 rules for Git commit messages have actually become established in the open source community?

My Top 5

• Title: start your commit message with a clear title that summarizes the changes introduced by the commit. The title should not be longer than 72 characters. 72 is the original convention limit, although most developers and projects recommend a limit of 50. It also named as 50/72 Message formatting.

• Spelling: write your message in the imperative (e.g. “fix typo” instead of “fixed typo” or “fixes typo”). This is a general Git convention and is based on the assumption that your commit will be read as If applied, this commit will ... fix typos

• Explain: how does this commit solve a specific problem? What effects does this commit trigger? Ticket IDs should not necessarily be in commit messages, but should be referenced in the pull request.

• No emojis: No. Leave it. Just stop. Emojis have no place in commit messages. Most tools and platforms can’t display them either. If you use a tool that renders emojis in commit messages, don’t be so selfish. Just no. We’re not in kindergarten.

• Optional context: leave a blank line after the title and include a more detailed description of the changes in the commit text. You can use this body to provide more information. Keep in mind, however, that a complete description of an issue does not belong in the individual Git commit message, but in the pull request.

Be nice to your fellow project members. Stick to standards.