git-pushing

Git Push Workflow

Stage only intended changes, create a conventional commit, and push to the remote branch.

When to Use

Automatically activate when the user:

• Explicitly asks to push changes ("push this", "commit and push")
• Mentions saving work to remote ("save to github", "push to remote")
• Completes a feature and wants to share it
• Says phrases like "let's push this up" or "commit these changes"

Safety Gates

Before staging, inspect git status --short --branch, confirm the intended files, and fetch the upstream branch when a concurrent push is plausible. Do not absorb unrelated dirty files.

Read repository policy before choosing the destination branch. If main or master is protected, or the repository defines a maintainer command such as merge:batch, create or use a topic branch and finish through the required pull-request checks. A user request to “push to main” describes the desired final state; it does not authorize bypassing server-side protection. Never keep retrying a direct push after a protected-branch rejection.

The helper requires an empty live index and a conventional commit message before it stages anything. It locks the live index, builds and validates the commit in an isolated temporary index, rejects -- without paths, and atomically updates the branch only if its parent is unchanged.

The helper honors branch.<name>.pushRemote, `