# Gfix

> Amend a git commit further back in the history.

- Skill: `ryanb/gfix` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add ryanb/gfix`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ryanb/gfix/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ryanb (https://skillmd.com/u/ryanb)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ryanb/gfix

---


# gfix — Amend a Past Commit

Use the `gfix` shell command to fold staged changes into a commit that is not the most recent. This is the preferred way to amend historical commits in this repo.

**MUST use `gfix`.** When this skill is loaded, every modification to a past commit goes through the `gfix` command. Do **not** reach for `git rebase -i`, hand-crafted `fixup!`/`amend!` commits, or `GIT_SEQUENCE_EDITOR=true git rebase --autosquash` directly — gfix already does all of this, with stash/restore guarantees and conflict handling.

## How gfix works

Source: `~/code/dotfiles/plugins/git.zsh` (the `gfix` function)

`gfix [-m <message>] <commit-sha>` does the following:

1. Guards against running during an in-progress git operation (rebase, merge, cherry-pick, etc.)
2. Stashes any unstaged changes (preserving the index)
3. Creates a fixup commit from whatever is currently staged:
   - With no `-m`: `git commit --fixup <commit-sha>` (content-only fixup)
   - With `-m <message>`: creates a manual `amend!` commit with subject `amend! <original-subject>` and body `<message>`, which autosquash then folds into the target (replacing its message, and including any staged changes; `--allow-empty` is used if nothing is staged)
4. Runs `GIT_SEQUENCE_EDITOR=true git rebase -i --autosquash <commit-sha>^` to automatically squash the fixup into the target commit
5. Restores any stashed unstaged changes

## When to use gfix

Use gfix when you need to amend a commit that is **not** the HEAD commit. For example:

- A review comment asks for a change to code introduced 3 commits ago
- You notice a typo or bug in an earlier commit while working on something else
- You want to keep a clean, logical commit history where each commit is self-contained

If you only need to amend the most recent commit, use `git commit --amend` instead.

## Steps

1. **Determine the safe range** — The target commit must be within the current branch's own commits, not on or before the base branch. Find the base branch via the tracked parent in `git config branch.$(git branch --show-current).parent`, falling back to `bin/base-branch` if that script exists. As a last resort, ask the user.

   The target commit **must** appear in `git log --oneline <base-branch>..HEAD`. If it does not, **stop and tell the user** — rewriting shared history would cause problems.

2. **Identify the target commit** — Use `$ARGUMENTS` to understand what the user wants fixed. List the safe commits with `git log --oneline <base-branch>..HEAD` and examine their diffs to find the commit that introduced the code the user wants changed.

3. **Make and stage the changes** — Edit the files, then `git add` only the files that belong to the target commit.

4. **Run gfix** — Pass the target commit SHA. Add `-m <message>` to also rewrite the target commit's message:

   ```bash
   gfix <commit-sha>
   gfix -m "new commit message" <commit-sha>
   ```

5. **Handle rebase conflicts** — If the rebase hits conflicts:
   - Read the conflicting files and resolve them
   - `git add` the resolved files
   - `git rebase --continue`
   - Repeat until the rebase finishes

6. **Verify** — Run `git log --oneline -10` to confirm the history looks correct. If relevant tests exist, run them.