AI Commit Message Writer

It is a convention for the first line of a commit: a type, an optional scope in brackets, a colon and a space, then a short description — fix(auth): reject tokens with no expiry claim. The usual types are feat and fix, which map onto minor and patch releases, alongside docs, refactor, perf, test, build, ci and chore. A blank line then an optional body carries the reasoning, and footers at the end hold references. The point is not tidiness for its own sake: tooling can read the type and work out what has changed since the last release without a person reading every message.

Because git diff compares your working tree against the staging area, and once you have run git add there is nothing between them left to show. The staged change — the one you are about to commit, and the one worth summarising — is git diff --staged, or --cached under its older name. For everything at once, staged and unstaged together, use git diff HEAD. When the change spans a branch rather than a single commit, git diff main...HEAD gives you the whole of it, which is usually far more than you want to paste anywhere.

The usual guidance is around fifty characters for the subject and a hard wrap at seventy-two in the body, and both numbers come from tooling rather than taste — git indents messages in some outputs, and eighty-column terminals were the assumption when the convention formed. Fifty is less a rule than a pressure: a subject that will not fit is usually describing more than one change. Write it in the imperative, completing the sentence if applied, this commit will — which is why the convention is add validation rather than added validation, and why a message that drifts into the past tense reads wrong in a log.

Why, almost always. The what is already in the repository and always will be: anyone can run git show and read the exact lines. The why lives in your head, and in a fortnight it will not live anywhere. The message that earns its keep answers the question somebody asks eighteen months later while running git blame on a line that looks pointless — what went wrong that made this necessary. Name the bug report, the incident, the limit you hit, the approach you tried first and abandoned. A summary of the mechanics is no substitute, because the reasoning was never in the input.

Treat it as sending the code somewhere, because that is what it is: the text in the box is posted to this site's AI route and on to the model that writes the message. What happens on the page itself is the reassuring part and the smaller part — there is no account and no saved history, the result lives in the tab until you close it, and starting a new run clears the previous one before the first word arrives. The sending is the bit to think about. If a credential is in your diff at all then it is already in your repository, so the answer is to rotate it rather than to trim the paste. Where the code genuinely cannot leave the machine, describe the change in prose instead — the same box takes either.

It is the part of the convention that drives version numbers. A commit that breaks what other people depend on takes either an exclamation mark after the type — feat(api)!: drop v1 endpoints — or a footer beginning BREAKING CHANGE: followed by what broke and what to do instead. Release tooling reads that marker and raises the major version; without it, a change that breaks every consumer ships as a minor release and nobody is warned. The marker describes the effect on people using your code, not the size of the diff: a one-character change to a default value can be breaking.

A hook, almost certainly commitlint running from commit-msg via husky or lefthook. It parses your subject against a ruleset — usually config-conventional — and refuses the commit when the type is not on the allowed list, the header is over its length limit, or the description begins with a capital or ends with a full stop. The error names the rule that failed, which is the quickest way to see what it wants. Nothing is lost when it fires: git keeps your text in .git/COMMIT_EDITMSG, so you can reopen that rather than retyping. A rule that is genuinely wrong for your project lives in commitlint.config.js and is meant to be changed.

For the most recent commit, git commit --amend rewrites the message. Further back, git rebase -i HEAD~5 and mark the commit as reword, which stops and opens an editor for that message alone. Both produce new commits with new hashes, and that is the whole difficulty — once a commit has been pushed and pulled by somebody else, rewriting it hands them a divergent history to reconcile. On a branch only you are using, push again with --force-with-lease, which refuses if the remote has moved since you last looked. On a shared branch, leave the wording wrong and be more careful with the next one.