Levandor

TechTeamer commit-message ruleset (push rejection)

3 min read

TechTeamer’s vuer repos enforce a GitHub repository ruleset on commit metadata: a push is rejected unless every commit subject in it matches a conventional-commit pattern. Two traps bite in practice — a default git revert message, and the 100-character subject cap.

For Agents

Before pushing to any TechTeamer vuer repo, check every commit subject in the range, not just the last one. A single non-conforming subject anywhere in the push rejects the whole push, and the fix is a history rewrite (rebase/commit --amend), which is far more expensive than getting the message right the first time.

The pattern

^(build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test)(!)?(\([^)]+\))?: [^\n]{1,100}

Reading it out:

  • One of the 11 allowed types, lowercase.
  • Optional ! (breaking change) and optional (scope).
  • Then a literal ": ".
  • Then 1–100 characters of subject, no newline.

Trap 1: git revert default messages are rejected

git revert <sha> generates:

Revert "feat: something"

That starts with Revert — not an allowed type — so the push is rejected. Use the revert type instead:

git revert --no-commit <sha>
git commit -m 'revert: feat: something'
# or: git revert -n <sha> && git commit -m 'revert(entrypoints): drop the .js shims'

Trap 2: the subject after the prefix is capped at 100 characters

The {1,100} applies to the text after type(scope): , so a long descriptive subject that would be fine under plain Conventional Commits still fails. Keep subjects short and push detail into the body.

Also enforced: branch naming

The same rulesets enforce branch names of the shape chore/FKITDEV-NNNN-… / feat/FKITDEV-NNNN-… (ticket-prefixed, conventional type). See nusz-1.9.11.47 for the first recorded hit.

Trap 3: the required branch name produces a REJECTED PR title

Every PR opened from the GitHub UI on a conforming branch starts non-conforming

GitHub derives the default PR title from the branch name, and the transformation breaks the pattern:

chore/FKITDEV-9197-cib-devel-update                          ← the branch (required shape)
Chore/fkitdev 9197 cib devel update                          ← GitHub's default PR title
chore: [fkitdev-9197] merge devel into customization/cib     ← conforming

The default misses on both counts — no lowercase type: prefix (it is Chore/, capitalised, slash-separated) and no bracketed lowercase ticket. This is structural, not occasional: the branch convention the rulesets require guarantees a title the rulesets reject.

Checklist item: open the PR, then immediately fix the title. Three PRs needed it in FKITDEV-9197.

gh pr edit resolves the repo from the working directory — pass -R

gh pr edit <n> -R TechTeamer/vuer_css --title 'chore: [fkitdev-9197] merge devel into customization/cib'

In a multi-repo round, especially with worktrees nested inside a repo, cwd inference is a coin flip.

Why a devel-update PR must be SQUASH-merged, not merge-committed

A preserving --merge of a devel-update PR drags every bracket-less devel commit onto customization/**, where the per-commit “Merge commit rules” ruleset (bracketed lowercase ticket, bypass_actors: NONE) rejects them — so merge-commit style is structurally impossible. The working path is gh pr merge --squash --admin: the squash collapses to ONE commit whose subject = the (compliant) PR title. Full four-ruleset breakdown + the --admin-skips-red-checks-not-ruleset distinction: release-cut-mechanics.

Graph View

Backlinks