commit-push

Commit and Push

Commit all local changes following Conventional Commits format and push to remote.

Gates

Complete in order. Do not run the next action until the Pass condition is satisfied (use command output as evidence, not memory).

1. Diff understood — Pass when: Outputs from git status, git diff, and git diff --cached are consistent with your one-sentence description of what changed (or you recorded that there is nothing to commit).
2. Commit line chosen — Pass when: You have a draft first line type(scope): description (or type: description if omitting scope) that matches the change set you intend to ship.
3. Staging matches intent — Pass when: After git add, git diff --cached --stat (and spot-check git diff --cached if needed) shows only the paths you meant to include; adjust staging before committing if not.
4. Push target confirmed — Pass when: Current branch and remote are the ones you intend (git branch -vv, git remote -v); then push.
5. Remote caught up — Pass when: git status is clean and git status -sb shows the branch is up to date with its configured upstream (no unexpected unpushed commits left for this task).

Step 1: Gather Context

Run these commands in parallel to understand the changes:

# See all untracked and modified files
git status

# See staged and unstaged changes
git diff
git diff --cached

# See recent commit messages for style reference
git log --oneline -10

Step 2: Analyze Changes

Review the changes and determine:

• Type: What kind of change is this?

  • feat - New feature or capability
  • fix - Bug fix
  • docs - Documentation only
  • refactor - Code restructure without behavior change
  • test - Adding or updating tests
  • chore - Maintenance, dependency updates
  • perf - Performance improvement
  • ci - CI/CD changes

• Scope: Which component is affected?

  • Examine the changed files and determine the appropriate scope
  • Use consistent scope names within the project (check git log for patterns)
  • (omit scope for cross-cutting changes)