
Git Commit Push
- 4 installs
- 13.2k repo stars
- Updated August 1, 2026
- gogf/gf
Review the git working tree, generate a Conventional Commits message from the actual diff, commit all changes on the active branch, and push to origin.
About
Inspects the working tree, derives a type(scope): description commit subject from the real diff and repo convention, commits with git add -A, and pushes the branch to origin. A developer uses it to commit and push current changes without hand-writing git commands.
- Conventional Commits subject generated from the actual diff
- Reads PULL_REQUEST_TEMPLATE for the repo's title convention
Git Commit Push by the numbers
- 4 all-time installs (skills.sh)
- Ranked #480 of 733 Git & Pull Requests skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/gogf/gf --skill git-commit-pushAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 4 |
|---|---|
| repo stars | ★ 13.2k |
| Last updated | August 1, 2026 |
| Repository | gogf/gf ↗ |
What it does
Review the git working tree, generate a Conventional Commits message from the actual diff, commit all changes on the active branch, and push to origin.
Files
Git Commit Push
Inspect the current repository changes, derive a concise commit subject that matches the repository convention, commit every current modification on the active branch, and push that branch to origin.
This skill is for execution, not just advice. When it triggers, actually run the git workflow unless the repository state makes that unsafe or impossible.
When To Use
- The user asks you to commit the current changes, with or without asking for push
- The user wants you to write the commit message from the diff instead of inventing one up front
- The user mentions the repo's PR or commit naming convention and wants you to follow it
- The user says things like "commit the current branch", "help me commit", "commit and push", "generate a commit message and push", or "send these changes to origin"
Core Behavior
1. Confirm you are inside a Git repository and detect the active branch with git branch --show-current. 2. Inspect the working tree before committing:
git status --short --branchgit diff --statgit diff --cached --statgit diff -- . ':(exclude)package-lock.json'or narrower path filters only when needed for readability
3. If the repository contains .github/PULL_REQUEST_TEMPLATE.MD, read it and treat its PR-title rules as the default commit-subject convention. 4. Generate a commit subject from the actual changed files and diff content, not from the user prompt alone. 5. Stage every current modification on the branch with git add -A. 6. Commit once with the generated message. 7. Push the current branch to origin with git push origin <current-branch>.
Commit Message Rules
The commit message is formatted as follows: <type>[optional scope]: <description> For example, fix(os/gtime): fix time zone issue + <type> is mandatory and can be one of fix, feat, build, ci, docs, style, refactor, perf, test, chore + fix: Used when a bug has been fixed. + feat: Used when a new feature has been added. + build: Used for modifications to the project build system, such as changes to dependencies, external interfaces, or upgrading Node version. + ci: Used for modifications to continuous integration processes, such as changes to Travis, Jenkins workflow configurations. + docs: Used for modifications to documentation, such as changes to README files, API documentation, etc. + style: Used for changes to code style, such as adjustments to indentation, spaces, blank lines, etc. + refactor: Used for code refactoring, such as changes to code structure, variable names, function names, without altering functionality. + perf: Used for performance optimization, such as improving code performance, reducing memory usage, etc. + test: Used for modifications to test cases, such as adding, deleting, or modifying test cases for code. + chore: Used for modifications to non-business-related code, such as changes to build processes or tool configurations. + After <type>, specify the affected package name or scope in parentheses, for example, (os/gtime). + The part after the colon uses the verb tense + phrase that completes the blank in + Lowercase verb after the colon + No trailing period + Keep the title as short as possible. ideally under 76 characters or shorter + If there is a corresponding issue, add either fixes #1234 (the latter if this is not a complete fix) to this comment
Examples
Commit message with description and breaking change footer
feat: allow provided config object to extend other configs
BREAKING CHANGE: `extends` key in config file is now used for extending other config filesCommit message with ! to draw attention to breaking change
feat!: send an email to the customer when a product is shippedCommit message with scope and ! to draw attention to breaking change
feat(api)!: send an email to the customer when a product is shippedCommit message with both ! and BREAKING CHANGE footer
feat!: drop support for Node 6
BREAKING CHANGE: use JavaScript features not available in Node 6.Commit message with no body
docs: correct spelling of CHANGELOGCommit message with scope
feat(lang): add Polish languageCommit message with multi-paragraph body and multiple footers
fix: prevent racing of requests
Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.
Remove timeouts which were used to mitigate the racing issue but are
obsolete now.
Reviewed-by: Z
Refs: #123Execution Rules
- Commit all current tracked and untracked changes in the working tree, because this skill is for "commit the current state" requests
- If there are no changes, say so clearly and stop before commit or push
- If
git branch --show-currentis empty, explain thatHEADis detached and stop unless the user explicitly asks you to commit from detachedHEAD - Never use
--force,--force-with-lease, or history-rewriting commands unless the user explicitly asks - If push fails because the remote branch moved, report the exact failure and stop instead of auto-rebasing or auto-merging
- Do not silently drop files from the commit unless the user asked to exclude them
Suggested Command Flow
git status --short --branch
git diff --stat
git diff --cached --stat
test -f .github/PULL_REQUEST_TEMPLATE.MD && sed -n '1,220p' .github/PULL_REQUEST_TEMPLATE.MD
branch_name=$(git branch --show-current)
git add -A
git commit -m "<generated-subject>"
git push origin "$branch_name"Inspect git diff --cached again after staging if the pre-stage diff was noisy or if untracked files materially change the scope.
Output Contract
When you use this skill:
- Tell the user which branch you committed
- Provide the final commit subject you used
- Mention that you staged all current changes
- Report the push target as
origin/<branch> - If commit or push did not happen, explain exactly why
Example
User request:
Generate a commit message that follows this repository's convention, then commit and push the current branchExpected behavior:
- Inspect the repo status and diff
- Generate a conventional subject from the real changes
- Run one commit for the whole current working tree
- Push the active branch to
origin