Commit

Turn the current working tree into one or more commits: group changes by intent, draft a Conventional Commits message per group, get your review, then apply.

1. Inspect the full tree

Re-derive the picture from scratch every time: git status, git diff, and git diff --staged together. Never treat whatever happens to already be staged as correct; re-plan the grouping from the full tree regardless of the current index.

A freshly initialized repo has no commits yet (an unborn branch): git log fails on it instead of returning empty. Check for this up front rather than letting a downstream git log call error out.

2. Group by intent

Each group becomes exactly one commit. A group is everything that serves one purpose:

• Don't split one logical change across commits just because it touches several files.
• Don't merge unrelated purposes into one commit just because they touch the same file: split at the hunk level (git add -p, or write and apply a partial patch) when a single file mixes two intents.
• If the whole tree really is one intent, one commit is the correct output. Grouping doesn't mean forcing a split that isn't there.
• Where changes have a dependency order (a refactor a following feature builds on), commit them in that order.