Release announcements, and the reasoning behind decisions the reference pages only state. Rules tells you what a rule does and how to configure it; these posts cover why it exists and what changed along the way.
Ask Claude Code or Cursor to commit for you and, by default, the commit comes out stamped:
Whether that line belongs in your history is a policy question, and open source has already given three different answers.
The open-source ecosystem is converging on a hard question: when a commit is written with AI assistance, how do we know — and how do we enforce the disclosure policy?
Python's discourse, Linux kernel's Assisted-by trailer, Fedora's AI policy,
Apache's disclosure guidelines — every major project is grappling with this.
But until now, there has been no tool at the CI level to enforce whatever
policy a project chooses.
Commit Check v2.11.0 introduces AI Attribution Governance — a new feature that detects known AI tool signatures in commit messages and lets projects decide whether to forbid them outright. To our knowledge, no existing tool enforces this kind of policy at the CI level.
More and more commits are written — or at least drafted — by AI agents and automation. So Commit Check is also built for machines — not just humans reading terminal output. This post covers the two features that make that possible: machine-readable JSON output and an import-friendly Python API.
Commit Check works the moment you install it, but its real strength shows up when you start shaping the policy to fit your team. This post covers everything from the default behavior to organization-wide shared configuration.
Most teams have a wiki page titled something like "How we write commit messages." It covers commit conventions, branch naming, sign-offs, and author email consistency — and then nobody reads it.
Commit Check exists to turn that wiki page into something Git actually enforces.