Expand description
git_commit_message — assert commit messages match a shape
(regex, max subject length, body required).
Two modes:
- HEAD-only (default,
since:omitted): validate the tip commit. Right shape for push-trigger CI and post-commit hooks. - Range (
since:set): validate every commit reachable fromHEADbut not fromsince. Right shape for pull-request CI, whereactions/checkoutchecks out a synthetic merge commit that the rule should never see. Setsince:to the PR base SHA (typically via${ALINT_BASE_SHA}env interpolation, with the env var sourced fromgithub.event.pull_request.base.shain the workflow). Merge commits in the range are skipped by default (include_merges: false); setinclude_merges: trueto lint them too.
Use cases: enforce Conventional Commits / Angular-style prefixes, cap the subject at a screen-friendly width (50–72), require commits that fix issues to include a body linking the issue.
Outside a git repo, with no commits yet, or when git isn’t on
PATH, the rule silently no-ops. Same advisory posture as
git_tracked_only and git_no_denied_paths: a rule about git
only fires when there’s git to inspect.
Bad since: refs (typo, or a shallow-clone gotcha that left
the ref out of local objects) hard-fail with a hint to widen
the checkout. The user asked for a range; silently falling back
to HEAD-only would mask the misconfiguration.
Check-only — alint can’t rewrite the user’s commit message, and
git commit --amend is a sensitive operation we don’t automate.