The Git 50/72 Rule: Where the Numbers Actually Come From, and What Really Enforces Them

The 50/72 rule is one of the most widely followed conventions in software development: keep a commit's subject line to 50 characters, leave a blank line, then wrap any body text at 72 characters per line. It's repeated in style guides, onboarding docs, and linting configs across the industry. What's less often mentioned is that Git itself enforces none of it — the numbers come entirely from the tools built around Git, and those tools don't all draw the line in the same place.

Reviewing a commit message against an older version? ClearDiff highlights exactly what changed between two pieces of text, instantly.

Git's Own Position: "Though Not Required"

Git's own documentation is explicit that this is a suggestion, not a rule the tool enforces: it describes starting a commit message with "a single short (less than 50 character) line" as "a good idea," not a requirement. There is no technical mechanism in core Git that rejects, warns about, or truncates a commit message of any length. A commit subject line could be 500 characters long and git commit would accept it without complaint. Everything that actually happens to a long commit message — truncation, warnings, rejected pushes — comes from something layered on top of Git, not from Git itself.

Where "72" Actually Comes From

The 72-character figure traces back to 80-column terminal displays, once the standard width for a terminal window. When git log displays a commit body, it adds four spaces of left padding. To keep the text visually centered and readable, convention adds four more characters of margin on the right — 80 minus 4 minus 4 leaves 72 characters for the actual text. It's a specific, deliberate piece of arithmetic, not an arbitrary round number.

Where "50" Actually Comes From

The 50-character subject line figure is generally traced to an analysis of commit messages in the Linux kernel codebase, which found that 50 characters was close to the natural, common length of a well-written commit summary — short enough to force a single, clear idea rather than a run-on description of several changes at once. The convention itself predates its most widely cited explanation: Git's own tutorial documentation recommended a short first line before Tim Pope's widely shared 2008 blog post popularized and expanded on the reasoning that's now commonly quoted. It's worth separating the two: the guidance is older and comes from the project itself, while the popular explanation of why is a later, well-argued gloss on it.

Neither 50 nor 72 is arbitrary, but neither is a Git rule either. They describe what made commit histories readable on the terminals developers actually used — a convention that outlived the specific hardware constraint that produced it.

What GitHub Actually Truncates — And Where the Confusion Comes From

GitHub's web interface does enforce a hard visual cutoff, but it's worth being precise about where, because two different GitHub behaviors get conflated. When committing a file edit directly through GitHub's own web editor, the commit title input field shows a warning once typing passes 50 characters — matching the subject-line convention exactly. Separately, GitHub's commit list view — where existing commits are displayed, regardless of how they were made — truncates any subject line beyond 72 characters, replacing the remainder with an ellipsis that can be clicked to reveal the full text. These are two different features triggering at two different thresholds, and articles describing "GitHub's limit" without specifying which one often blend them into a single, slightly wrong number.

Different Tools Draw the Line in Different Places

Outside of GitHub, the 50/72 convention isn't applied uniformly even by tools that reference it directly. Gerrit, the code review tool, ships with configurable defaults of exactly 50 and 72 characters for subject and body — a direct implementation of the convention, citing Git's own tutorial and Tim Pope's post as its source. GitLab takes a different approach entirely: by default it doesn't truncate a commit title at all until it exceeds 100 characters, at which point it cuts the display to 80 characters — numbers that don't match the 50/72 convention at all, though GitLab has made this configurable. Individual projects sometimes set their own hook-enforced limits distinct from either default; the ITK medical imaging toolkit, for example, enforced a 78-character hard limit through its own pre-commit hook before a request to lower it to 72 specifically to match GitHub's display truncation and avoid mid-word cutoffs in pull request views.

Why the Convention Persists Anyway

Given that Git doesn't enforce any of this, and the tools built on top of it don't even agree on the exact numbers, the 50/72 rule survives for a simpler reason than technical necessity: a short, well-formed subject line reads cleanly in git log --oneline, in a terminal, in an IDE's commit history panel, and in a pull request list, regardless of which specific tool's truncation threshold is doing the cutting. Writing to the stricter of the common numbers — 50 for the subject — means the message displays intact almost everywhere, rather than gambling on which platform's particular cutoff a commit happens to be viewed through. It's the same lesson that comes up across nearly every platform-specific character limit covered in this series: the character limits by platform overview makes the same point about designing for the strictest consumer, not the most generous one.

---

The honest summary: there is no Git-level character limit on a commit message, full stop. The 50/72 rule is a widely followed convention, rooted in real 80-column terminal math and an analysis of what makes a commit summary readable — but the tools that actually enforce something resembling it, GitHub, GitLab, and Gerrit among them, each draw their own line, and none of those lines is guaranteed to be exactly 50 or exactly 72. Following the convention isn't about satisfying a technical requirement; it's about writing a message that survives being displayed by tools that don't agree with each other.