{"id":1166,"date":"2023-10-17T16:17:08","date_gmt":"2023-10-17T16:17:08","guid":{"rendered":"https:\/\/www.devopssupport.in\/blog\/?p=1166"},"modified":"2023-10-26T16:23:21","modified_gmt":"2023-10-26T16:23:21","slug":"how-to-write-git-commit-messages","status":"publish","type":"post","link":"https:\/\/www.devopssupport.in\/blog\/how-to-write-git-commit-messages\/","title":{"rendered":"How to write Git Commit Messages"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

When developers first step into the world of Git, they often encounter a certain discomfort, especially when it comes to crafting meaningful commit messages. The Git commit message, which encapsulates the changes made and why they were made, is a crucial part of version control. Developing good committing habits early in your career is essential. In this guide, we’ll explore how to improve your Git commit messages and why it matters.<\/p>\n\n\n\n

The Importance of Quality Commit Messages<\/h3>\n\n\n\n

Imagine this scenario: you open a repository, run git log<\/code>, and find a list of cryptic commit messages like “Fix style” or “Update code.” Months later, you revisit the project and have no idea what these messages mean. Sound familiar? Well, this is a common issue with poorly written commit messages. Quality commit messages provide essential context and save you and your teammates time when troubleshooting or understanding past changes.<\/p>\n\n\n\n

The Anatomy of a Commit Message<\/h3>\n\n\n\n

A Git commit message has two main parts: the subject line and the body.<\/p>\n\n\n\n

    \n
  • Subject Line:<\/strong> This should be concise, not exceeding 50 characters. It should start with a capital letter and use the imperative mood (e.g., “Add,” “Fix,” “Update”). The subject line provides a high-level overview of the change.<\/li>\n\n\n\n
  • Body:<\/strong> The body of the message is where you can explain in more detail. It should be wrapped at 72 characters and answer the questions of “why” and “what.”<\/li>\n<\/ul>\n\n\n\n

    Steps to Writing Better Commit Messages<\/h3>\n\n\n\n

    Let’s dive into practical steps to improve your commit messages:<\/p>\n\n\n\n

    1. Capitalization and Punctuation<\/h4>\n\n\n\n

    Always start the subject line with a capital letter and don’t end it with punctuation. Conventional Commits, a popular convention, encourages using all lowercase.<\/p>\n\n\n\n

    2. Mood Matters<\/h4>\n\n\n\n

    Use the imperative mood in the subject line. This creates a tone of giving an order or request. For example, “Fix the dark mode toggle state” is more appropriate than “Fixed the dark mode toggle state.”<\/p>\n\n\n\n

    3. Specify the Type of Commit<\/h4>\n\n\n\n

    It’s beneficial to categorize your commits. Use a consistent set of words to describe your changes. For example, “Bugfix,” “Update,” “Refactor,” or “Bump.” This helps in classifying and searching for specific types of changes.<\/p>\n\n\n\n

    4. Watch the Length<\/h4>\n\n\n\n

    Keep the subject line short, ideally under 50 characters, and restrict the body to 72 characters per line. This ensures messages are concise and readable.<\/p>\n\n\n\n

    5. Content Clarity<\/h4>\n\n\n\n

    Be direct and avoid filler words and phrases. Think like a journalist, aiming to answer the “what” and “why” questions. Pretend that the reader has no prior knowledge of the change and needs a clear explanation.<\/p>\n\n\n\n

    Conventional Commits<\/h3>\n\n\n\n

    Conventional Commits is a widely adopted format that provides structured commit messages. It uses the format: <type>[optional scope]: <description><\/code>. The type<\/code> can include values like “feat” (new feature), “fix” (bug fix), “chore” (maintenance), and more. The optional scope specifies the part of the codebase affected, and the description provides a concise summary.<\/p>\n\n\n\n

    This convention enhances consistency in commit messages and can be paired with tools like Commitizen to enforce standards.<\/p>\n\n\n\n

    Commit Message Comparisons<\/h3>\n\n\n\n

    Let’s compare some examples to see the difference quality commit messages make:<\/p>\n\n\n\n

    Good:<\/strong><\/p>\n\n\n\n

      \n
    • feat: Improve performance with lazy load implementation for images<\/code><\/li>\n\n\n\n
    • chore: Update npm dependency to the latest version<\/code><\/li>\n\n\n\n
    • Fix bug preventing users from submitting the subscribe form<\/code><\/li>\n\n\n\n
    • Update incorrect client phone number within the footer body per client request<\/code><\/li>\n<\/ul>\n\n\n\n

      Bad:<\/strong><\/p>\n\n\n\n

        \n
      • Fixed bug on the landing page<\/code><\/li>\n\n\n\n
      • Changed style<\/code><\/li>\n\n\n\n
      • Oops<\/code><\/li>\n\n\n\n
      • I think I fixed it this time?<\/code><\/li>\n\n\n\n
      • Empty commit messages<\/li>\n<\/ul>\n\n\n\n

        By following these guidelines, your commit messages can become valuable documentation, saving you and your team time and frustration. Whether you’re working solo or in a collaborative development environment, investing a little extra effort in crafting clear and meaningful commit messages pays off in the long run.<\/p>\n","protected":false},"excerpt":{"rendered":"

        When developers first step into the world of Git, they often encounter a certain discomfort, especially when it comes to crafting meaningful commit messages. The Git commit… <\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[469,467,466,468],"class_list":["post-1166","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-commit-message-comparisons","tag-git-commit-messages","tag-how-to-write-git-commit-messages","tag-importance-of-quality-commit-messages"],"_links":{"self":[{"href":"https:\/\/www.devopssupport.in\/blog\/wp-json\/wp\/v2\/posts\/1166","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopssupport.in\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopssupport.in\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopssupport.in\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopssupport.in\/blog\/wp-json\/wp\/v2\/comments?post=1166"}],"version-history":[{"count":1,"href":"https:\/\/www.devopssupport.in\/blog\/wp-json\/wp\/v2\/posts\/1166\/revisions"}],"predecessor-version":[{"id":1168,"href":"https:\/\/www.devopssupport.in\/blog\/wp-json\/wp\/v2\/posts\/1166\/revisions\/1168"}],"wp:attachment":[{"href":"https:\/\/www.devopssupport.in\/blog\/wp-json\/wp\/v2\/media?parent=1166"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopssupport.in\/blog\/wp-json\/wp\/v2\/categories?post=1166"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopssupport.in\/blog\/wp-json\/wp\/v2\/tags?post=1166"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}