In this page

Overview

In this documentation section, you'll find practical guides on how to configure your commit policy to enforce frequently used rules. You have the flexibility to implement your custom conventions or adopt one of the common conventions.

Custom conventions

Looking for ideas to set up practical rules for your team's conventions? These pages offer inspiration and ready-to-use YAML configuration snippets that you can directly copy into your commit policy configuration file.

Feel free to mix and match these conventions, using only the ones that fit your needs. You can also introduce them gradually, perhaps starting with just commit messages.

  1. Commit message conventions
  2. Pull request title conventions
  3. Pull request description conventions
  4. Pull request source branch conventions
  5. Pull request target branch conventions

Common conventions

Standardized commit messages play a crucial role in maintaining a clear and manageable Git history. They enhance readability, facilitate automation, and improve collaboration within development teams. This section outlines two popular commit message conventions.

Enforce the Git 50/72 rule

The Git 50/72 rule is a widely adopted convention that originated from the Linux Kernel project. Its primary goal is to ensure commit messages are concise and easy to read, especially when viewed in various Git tools or email clients.

This rule stipulates two main constraints:

  • The subject Line of your commit message should be no more than 50 characters. This brevity ensures the subject is scannable and provides a quick summary of the commit's purpose.
  • Each line in the body of your commit message should not exceed 72 characters. This limit prevents horizontal scrolling in most terminals and Git log viewers, making the commit message much more comfortable to read.

Adhering to the 50/72 rule significantly improves the clarity and maintainability of your Git history, making it easier for developers to understand changes at a glance.

👉 How to enforce the Git 50/72 rule for Bitbucket cloud? (our blog post)

Enforce the Conventional Commits style

The Conventional Commits style is a more structured approach built on top of commit messages, aiming to create an explicit and machine-readable commit history. This specification provides a standardized set of rules for commit messages, which in turn makes it easier to develop automated tools that can parse and act upon commit history.

Key aspects of Conventional Commits include:

  • Commit messages follow a defined structure, typically including a type (e.g., feat, fix, chore), an optional scope, and a descriptive subject. This consistent format allows for easy parsing.
  • The explicit nature of Conventional Commits enables the creation of automated tools for tasks like generating changelogs, automatically determining semantic version bumps (SemVer), and enforcing commit message standards.
  • This convention works well with Semantic Versioning (SemVer) by clearly describing features (feat), bug fixes (fix), and breaking changes (BREAKING CHANGE) within commit messages. This allows for automated version bumping based on the type of changes introduced.

By enforcing the Conventional Commits style, teams can achieve a highly organized and automatable commit history, leading to more efficient release management and better communication of changes.

👉 How to enforce the Conventional Commits style for Bitbucket cloud? (our blog post)

Questions?

Ask us any time.