Updated May 2026 with policy-as-code enforcement for Bitbucket Cloud and AI-assisted commit guidance.
| Part | Limit | Notes |
|---|---|---|
| Subject line | Max 50 characters | Imperative mood, no trailing period |
| Blank line | Required if there are one or more body lines | Separates subject from body |
| Body lines | Max 72 characters each | Optional, wrap manually |
What is the Git 50/72 rule?
The Git 50/72 rule is a formatting standard for commit messages: the subject line must be 50 characters or fewer, followed by a blank line, with any body text wrapped at 72 characters per line. It is not specific to Git. The same convention applies to any version control system. It originated with the Linux Kernel project and has since become the de facto standard across the industry.
Low standard commits ruin traceability
Concise, straightforward messages can save you a ton of time in case you need to dig deep into the project history. Programmers tend to write one-word commit messages that do not tell much later in time and make traceability practically impossible. Other times those messages are more like long descriptions that are hard to follow. Applying this rule enforces well-formatted messages with the right level of detail.
Using Jira and Bitbucket Cloud?
Better Commit Policy is available for Bitbucket Cloud to enforce commit message standards like the 50/72 rule, Conventional Commits, Jira work item keys, and more - directly in your Bitbucket pull request workflow.
✅ Install Better Commit Policy Connector for Bitbucket Cloud
👉 Learn more about enforcing commit rules in Bitbucket Cloud
The rules of the game
The rule is simple:
- Summary: maximum 50 characters long first line
- Then a blank line
- Description: arbitrary number of maximum 72 characters long lines, at most one blank line between them (This part is optional. For trivial commits you may not want to write any details at all.)
Why 50 and why 72?
Well, these are most definitely not random values, but the result of analyzing the Linux Kernel codebase for ideal values. Plus, they work very well in popular development tools. Git log output, terminal viewers, and code review interfaces all benefit from consistent line lengths.
The 50/72 rule and AI-generated commits
AI coding assistants such as GitHub Copilot, Cursor, and JetBrains AI generate commit messages automatically. They often produce verbose subject lines that exceed 50 characters, or long unbroken body text with no line wrapping.
This makes the 50/72 rule more relevant in 2026, not less. When commit messages are AI generated rather than hand-written, the only reliable way to enforce length standards is at the policy layer, not through developer habit. A commit policy that enforces 50/72 catches AI-generated messages that are too long before they reach the main branch, regardless of which tool generated them.
How to enforce the 50/72 rule in Bitbucket Cloud
Bitbucket Cloud has no server-side hook mechanism. It cannot reject a commit or block a pull request merge based on message length. This is a platform constraint, not a configuration option. Enforcing the 50/72 rule requires an app-layer policy.
Better Commit Policy for Jira Cloud together with Better Commit Policy Connector for Bitbucket Cloud provides the missing enforcement layer.
Rules are defined in a .commitpolicy.yml file placed in the root of the repository, version-controlled alongside your code.
Here is a ready-to-copy configuration that enforces the 50/72 rule along with a few basic rules for the pull request:
- The pull request title has to be 5 characters or more and must start with a valid work item key.
- The referenced work item(s) has to be in the In Progress status category and their assignee or reporter must be the pull request author.
- The pull request description has to be at least 10 characters long.
Start using this policy by overwriting your current .commitpolicy.yml file with the code below, and replacing <connection-id> with your VCS connection ID (keep the quotation marks around the string).
commit-policy:
name: "Git 50/72 commit policy"
description: "Enforces the 50/72 rule: subject line max 50 characters, body lines max 72 characters."
vcs-connection:
id: "<connection-id>"
commit:
rejection-message: "Subject line must be 50 characters or fewer. If you add a body, separate it with a blank line and wrap each line at 72 characters."
message:
pattern: '.{1,50}(\n\n(.{0,72}(\n|$))*)?'
work-item:
jql: 'statusCategory="In Progress" and assignee="$commit.author" or reporter="$commit.author"'
count: "1+"
non-matching: reject
pull-request:
rejection-message: "Write a 5+ char long pull request title, starting with a work item key! Also, write a 10+ char long pull request description that summarizes the PR!"
title:
pattern: '[A-Z][A-Z\d]+-\d+\s+(\S\s*){5,}'
work-item:
jql: 'statusCategory="In Progress" and assignee="$pull-request.author" or reporter="$pull-request.author"'
count: "1+"
non-matching: reject
description:
pattern: '(\S\s*){10,}'
setting:
reject-on-error: true
Do you want to customize this commit policy? Read the configuration reference.
For a deeper look at what pull request rules you can enforce in Bitbucket Cloud beyond commit messages, see Pull request rules in Bitbucket Cloud.
When a developer opens a pull request, the policy check runs automatically as a merge check. Non-conformant commits are flagged. On Bitbucket Premium, they are blocked from merging. Developers see the violation directly in Bitbucket and can fix it before it reaches the main branch.
For teams that want to catch violations even earlier, local checks run the same policy on the developer's machine before the commit is pushed, so nothing non-conformant leaves the local repository.
For copy-ready commit messages you can paste into your workflow, see these Git commit message templates you can copy.
Make the 50/72 rule a team standard
Knowing the rule is the easy part. The hard part is keeping every developer and every AI assistant consistent over time. A commit policy enforces the standard automatically, so your team does not have to rely on code review to catch formatting issues that should never have existed in the first place.
