SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsgit-workflow

git-workflow

Office & productivity

View repository

Updated 10-15 20:35

About this skill

Default workflow

  1. Confirm the current state and determine the paths this task is responsible for:
git status -sb
  1. Get Assisted-by info:

<skill_dir> is the folder where the current SKILL.md is located. The script must be run directly as an executable command, do not use uv run python or python。

(cd <skill_dir> && ./scripts/codex_git_commit.py)

Incorrect example:

uv run python skills/git-workflow/scripts/codex_git_commit.py
python skills/git-workflow/scripts/codex_git_commit.py
  1. Create a scope-controlled commit:
git commit --only \
  -m "type(scope): concise summary" \
  -m "Optional body explaining the change." \
  --trailer "Co-authored-by: Name <name@example.com>" \
  --trailer "Assisted-by: <agent-name>:<model-name>" \
  -- <paths-owned-by-current-task>
  1. Verify the commit scope:
git show --name-status --oneline --no-renames HEAD
  1. If a push is needed, first confirm the state, then push according to the repository and user requirements:
git status -sb
git push <remote> <branch>

Path scope

  • <paths-owned-by-current-task> Include only the files or directories this task is responsible for; when multiple Agents share the same worktree, follow this rule as well.
  • The target can be a file, or a directory fully owned by the current task; for large numbers of generated files, prefer passing a directory, for example gen/。
  • If the directory contains unrelated changes, switch to more precise file or subdirectory paths.
  • If the same file contains changes from the user or other Agents, stop first and explain the situation; do not force a commit.
  • Do not clean up, reset, restore, or stash unrelated changes just to commit the current task.
  • By default, no need to git add；git commit --only -- <paths> will directly commit the current working tree contents of these paths.

Commit message

  • Commit messages use concise, precise English.
  • Recommended format:type(scope): short summary, following Conventional Commits。
  • common type：feat、fix、refactor、docs、test、chore
  • summary Focus on the result; if there is no suitable scope, it may be omitted.
  • If the commit contains a breaking change, the title and footer must both indicate it:
git commit --only \
  -m "type(scope)!: concise summary" \
  -m "BREAKING CHANGE: describe the impact and required migration." \
  --trailer "Assisted-by: <agent-name>:<model-name>" \
  -- <paths-owned-by-current-task>
  • BREAKING CHANGE: The footer should explain the impact scope and migration method; do not just repeat the title.
  • The keyword must be written as BREAKING CHANGE:, not as BREAK CHANGE:。
  • Use -mfor the commit title and body; use --trailer。
  • If the commit contents include substantive participation from an AI coding assistant, use --trailer "Assisted-by: <agent-name>:<model-name>" to append a trailer.
  • When adding multiple trailers such as Co-authored-by、Reviewed-by、Assisted-by , reuse --trailer "Key: Value"; do not manually assemble a trailer block with multiple -m .
  • After committing, you can use git show -s --format=%B HEAD | git interpret-trailers --parse to verify the trailer parsing result.
  • When using shell to execute git commit -m ... , do not directly put unescaped backticks in the commit title or body `。

Branches and push

  • If the repository or user has additional restrictions, such as protected branches, release processes, or prohibition of automatic pushes, follow these restrictions first.
  • For daily branch switching, prefer git switch; to restore the working tree or staging area, prefer git restore; avoid git checkout。
  • When creating branches, try to follow Conventional Branch。
  • For Git write operations involving the real index / refs, execute serially by default; do not call multiple git commit、git push or other write operations in parallel.
  • If you encounter .git/index.lock, first determine whether there are other active Git processes.
  • Before pushing, use git status -sb to confirm that this commit, branch, and working tree state match expectations.

Update MR/PR branch

  • When it is necessary to resolve conflicts or the behind state between an MR/PR and the target branch, by default prefer merging the target branch into the source branch, rather than rebasing.
  • Only switch to rebase when the user explicitly requests a rebase, or when the repository/platform has additional constraints requiring a linear history.