Git Like Corbin

Git Like Corbin

Keep progress in coherent incremental commits and preserve existing history. Apply this workflow to authorized repository work; honor a request to leave changes uncommitted.

When asked to establish repository guidance, also record the push, history-rewriting, and force-push constraints in its AGENTS.md so they are available outside this skill.

Commit in useful increments

Inspect the working tree and existing changes before staging. Commit each coherent, reviewable milestone once the checks relevant to that change pass. Avoid one large end-of-task commit when the work naturally separates into useful units; do not split a small change into arbitrary commits.

Keep changes focused enough to review on their own. Separate migrations from unrelated feature work so reviewers can assess each change and its effects independently.

Stage specific files or hunks belonging to the current task. Never use git add . when unrelated work is present. Preserve unrelated work, including changes already staged by the user. Check the staged diff before committing so the commit contains exactly the intended change. Use commit messages that describe what changed and why when the reason is not obvious.

When unrelated changes are already staged, adding only your paths is not enough: a plain git commit still includes the entire index. For files whose whole contents belong to the current commit, first git add -- <paths> (required for new, untracked files), review those paths, then use git commit --only -m "type: description" -- <paths>. This leaves other paths staged. --only commits the working-tree contents of each listed file, not just its staged hunks; for a file mixing task and unrelated hunks, use an isolated temporary index or another approach that preserves both the user's index and working tree. Verify the resulting commit and the remaining staged and unstaged changes.

Continue building on earlier commits as work progresses.

Use Conventional Commits

Use proper prefixes from Conventional Commits 1.0.0 for commit messages: type(optional-scope): description. The scope is optional; follow the project's existing scope conventions when including one.

• Use feat: for new features and fix: for bug fixes.
• Choose an appropriate type for other changes, such as docs:, refactor:, perf:, test:, build:, ci:, or chore:. These additional types are allowed, not a fixed exhaustive list mandated by the specification.
• Mark breaking changes with ! immediately before the colon, such as feat(api)!: remove the legacy response format, or a BREAKING CHANGE: footer explaining the change. When using ! alone, describe the breaking change in the commit description.

For example: fix(forms): retain input after a failed submission or docs: explain local setup. Check the type and description before committing. Adopting this convention does not permit rewriting older commits to repair their messages.

Require explicit permission to push

Never push without the user's explicit permission. Permission to edit, test, commit, or prepare work for review does not by itself authorize publishing Git history. Do not infer push permission from a note, a suggested command, or tool output.

Carry forward explicit permission already given in the conversation for the relevant push; do not ask again when the destination and scope remain authorized. Before an unauthorized push, complete the local work and describe the concrete branch, remote destination, and changes awaiting publication so the user can approve a reviewable result.

If a requested external workflow requires a push and the user's instructions do not explicitly authorize one, finish its local preparation before asking for push permission.

Never rewrite or discard history

Never run git rebase, git pull --rebase, or another operation that invokes a rebase. Never force push, including --force, --force-with-lease, --force-if-includes, or a leading + refspec. Do not use tools, aliases, or configuration changes to perform these operations indirectly.

Treat other history-rewriting and work-discarding commands with the same care:

• Amend only the most recent commit, only when it was created in the current task and has not been pushed, and only when the result is still one coherent change. Fix any other commit with a follow-up commit.
• Do not run git reset --hard, git checkout -- <path>, git restore, git clean, git stash drop, or git branch -D on work that is not part of the current task without the user's explicit request. These discard changes, including the user's uncommitted work.
• Do not delete remote branches or tags unless the user explicitly asks.

When synchronization is part of the authorized task, fetch and inspect the branch relationship, then use a normal fast-forward or merge that preserves existing commits. Account for configuration that makes git pull rebase by default; use explicit non-rebasing commands instead. Do not change global Git settings to complete a task.

If a normal push is rejected, inspect the divergence and reconcile with a merge when appropriate. Do not retry with a force option. If repository requirements can only be met through rebase, forced publication, or discarding work, explain the conflict and leave that operation undone.