1.4. Standards: Commit Message: The 50‐72 Rule: A Simple Guide

The 50/72 rule is a widely adopted convention for formatting Git commit messages. It provides a clear and concise structure that makes it easier to understand the changes made in each commit. The rule breaks down as follows:

1. Subject Line (50 Characters or Less):

   • Summarize the key change in a brief, imperative sentence (e.g., "Fix typo in README," "Add new user registration feature").
   • Use the present tense.
   • Avoid vague or overly general messages.
   • Use imperative verbs:
     • Add (e.g., "Add a change to the code.")
     • Clean (e.g., "Cleaned unwanted files")
     • Fix (e.g., "Fix the broken build.")
     • Improve (e.g., "Improve the code documentation.")
     • Merge (e.g., "Merge the branch into develop.")
     • Refactor (e.g., "Refactor the class for better readability.")
     • Remove (e.g., "Remove the duplicate files.")
     • Test (e.g., "Test the new feature thoroughly.")
     • Update (e.g., "Update the dependencies.")

2. Body (72 Characters per Line, Optional):

   • Provide more context and details about the change. Explain the motivation behind the change, the problem it solves, and any relevant implementation details.
   • Use complete sentences.
   • Wrap lines at 72 characters to ensure readability in various environments (e.g., terminals, code editors).

3. Blank Line:

   • Separate the subject line and body with a single blank line.

Example Overview:

Update user profile validation (50 characters)

Implement stricter validation rules for user profile fields to prevent invalid data entry. Added checks for:

* Minimum password length (8 characters)
* Valid email format
* Unique username

Updated the UI to display appropriate error messages. (72 characters)

Example Reality:

Fix #123: Update error handling in authentication module

This commit enhances error detection and adds comprehensive logging to address frequent issues reported by users.

Why the 50/72 Rule Matters:

• Readability: Makes commit history easier to scan and understand.
• Maintainability: Helps future developers (including yourself) grasp the reasoning behind past changes.
• Collaboration: Provides context for code reviews and discussions.
• Automation: Well-formatted commit messages can be used by tools for automated changelog generation or issue tracking integration.

Tips for Writing Great Commit Messages:

• Be Specific: Avoid vague messages like "Update code" or "Fix bug."
• Explain Why, Not Just What: Describe the problem the commit solves and the motivation behind the change.
• Focus on One Change: Each commit should ideally represent a single, logical change.
• Review Your Message: Before committing, double-check that your message is clear, concise, and accurately describes the change.