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 typosExplain: 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.
Related articles
- 7 min read
How to migrate .NET versioning from x.x.x.x to SemVer
Many long-lived .NET repositories did not start with semantic versioning. They grew up with major.minor.build.revision, often set in …
- 7 min read
Modern versioning for ASP.NET Core and web apps and how to produce idempotent artifacts
ASP.NET Core applications are usually released often enough that versioning stops being a documentation concern and turns into delivery …
- 8 min read
Modern versioning for .NET desktop apps and how to produce idempotent artifacts
Desktop software makes versioning visible in a way that web systems often do not. A backend can hide a surprising amount of release …
BEN ABT
Ben is Chief Engineering Officer and Principal Software Engineer at Medialesson.de, with a strong focus on .NET and Microsoft Azure. In his professional role, he designs and builds highly scalable platforms for hybrid and cloud-based scenarios. He also advises companies and C-levels on migrating to the sovereign cloud.
He runs myCSharp.de, the largest and most active German-speaking C# community forum, actively contributes to both his own and external open-source projects and regularly shares his knowledge through his blog, at community events, conferences and as a writer for technical magazines.
Let's Work Together
Looking for an experienced Platform Architect or Engineer for your next project? Whether it's cloud migration, platform modernization or building new solutions from scratch - I'm here to help you succeed.