Enter git commit --fixup — a powerful flag that, combined with git rebase --autosquash, lets Git automatically arrange and squash your messy commits into a clean history. Here's how to use it.

What is git commit --fixup?

git commit --fixup creates a new commit that is explicitly marked as a fixup for an earlier commit. The key difference from --amend:

• git commit --amend: rewrites the most recent commit in place (changes its hash).

• git commit --fixup: creates a new commit prefixed with fixup!, which rebase --autosquash will later merge into its target automatically.

When combined with git rebase -i --autosquash, you can:

• Add forgotten files to an earlier commit

• Fix typos or bugs that belong to a previous commit

• Squash multiple related commits into one — automatically, without manual reordering

The Traditional Problem

Consider this common scenario:

git commit -m "wip: add authentication"
git commit -m "fix: typo in auth"
git commit -m "add tests for auth"
git commit -m "update auth logic"
git commit -m "fix off-by-one error"
git commit -m "wip: add authorization"
git commit -m "refactor auth module"

Seven commits for what should be one cohesive "Add authentication" feature. Without --fixup, you'd open git rebase -i and manually mark each commit as squash or fixup — repetitive and easy to get wrong.

The Basic Fixup Workflow

Here's the pattern:

# 1. Make your original commit
git commit -m "feat: add user authentication"

# 2. Later, realise you forgot something — add it as a fixup
git add password-reset.ts
git commit --fixup=HEAD

# 3. When ready to clean up, run autosquash
git rebase -i --autosquash HEAD~2

The --fixup=HEAD flag creates a commit named fixup! feat: add user authentication. When you run rebase --autosquash, Git automatically moves that commit directly after its target and marks it fixup in the interactive editor — you just save and close.

Step-by-Step: Fixup with autosquash

Say your log looks like this:

abc1234 feat: implement login
def5678 fixup! feat: implement login
ghi9012 wip: update docs
jkl3456 fixup! feat: implement login

Run:

git rebase -i --autosquash HEAD~4

Git automatically opens the editor pre-arranged as:

pick abc1234 feat: implement login
fixup def5678 fixup! feat: implement login
fixup jkl3456 fixup! feat: implement login
pick ghi9012 wip: update docs

Save and close — Git squashes all three login commits into one and leaves the docs commit untouched. No manual reordering needed.

Real-World Example: Bug Fix with Multiple Passes

# Initial fix
git commit -m "fix: handle null pointer in user service"

# Test reveals another case
vim user.service.ts
git add user.service.ts
git commit --fixup=HEAD

# Add a regression test
git add user.test.ts
git commit --fixup=HEAD

# Log now shows:
# abc1234 fix: handle null pointer in user service
# def5678 fixup! fix: handle null pointer in user service
# ghi9012 fixup! fix: handle null pointer in user service

# Clean up
git rebase -i --autosquash HEAD~3
# All three combined into one clean commit automatically

Real-World Example: Multi-Step Feature

You want this final history:

• feat: add authentication system

• refactor: clean up auth flow

But your current log is:

f47ac8 refactor: clean up auth flow
ba3d92 wip: add logout
8c7e1a wip: add token refresh
4a5b6c fix: handle edge case
9c8d7e wip: add login form
2a3b4c wip: setup auth context

Run git rebase -i HEAD~6 and arrange:

pick   2a3b4c wip: setup auth context
squash 9c8d7e wip: add login form
fixup  4a5b6c fix: handle edge case
fixup  8c7e1a wip: add token refresh
squash ba3d92 wip: add logout
pick   f47ac8 refactor: clean up auth flow

Git squashes the first five into one, opens the editor so you can write a clean message like feat: add authentication system, then keeps the refactor commit separate.

Best Practices

Set autosquash globally

Save yourself from typing --autosquash every time:

git config --global rebase.autoSquash true

Now git rebase -i HEAD~N automatically honours fixup! commits.

Write good original messages

Since fixup commits inherit the target's message, a descriptive original message means you won't need to edit anything when squashing:

# Bad — you'll need to rewrite this during squash
git commit -m "fix"

# Good — already describes the final state
git commit -m "fix: handle null pointer in auth service when user not found"

Test after rebasing

git rebase -i --autosquash HEAD~5
npm test
# If tests fail, recover from reflog:
git reflog
git reset --hard HEAD@{1}

Back up before large rebases

git branch backup-before-cleanup
git rebase -i HEAD~10
# If something goes wrong:
git reset --hard backup-before-cleanup

Common Pitfalls

• Don't rebase public history. If commits are already on a shared branch, use merge instead. Check first: git log origin/main..HEAD. If the output is empty, don't rebase.

• Force-push safely. After rebasing a feature branch, use git push --force-with-lease instead of --force to avoid overwriting a teammate's push.

• Don't squash too aggressively. Three focused commits reviewable on their own are better than one giant commit that's impossible to review.

• Resolve conflicts carefully. If a conflict arises mid-rebase, edit the file, stage it with git add, then git rebase --continue. If it gets messy, git rebase --abort returns you to where you started.

Troubleshooting

Git doesn't recognise --fixup: ensure you're on Git 2.24 or later (git --version).

Squashed commit has the wrong message:

git commit --amend   # if it's the most recent commit
# or
git rebase -i HEAD~2  # to edit an earlier commit interactively

Unexpected conflicts during rebase: abort, review what changed between the commits you're squashing, and try again with a tighter range.

Summary

git commit --fixup combined with rebase --autosquash is the fastest way to keep your commit history clean without the manual overhead of interactive rebase every time. The workflow is simple: commit normally, mark corrections with --fixup as you go, then run one rebase --autosquash command before opening your PR. Git does the reordering and squashing for you.

Understanding Git’s DAG structure transforms Git from a set of memorized commands into a predictable, powerful tool. Instead of asking “what command do I run?” you’ll ask “what structure do I want to create?” This mental model helps you reason about complex situations, debug issues, and perform advanced operations with confidence.

In this guide, we’ll explore Git’s internal graph structure from first principles. You’ll learn how commits, branches, and references fit together, how to visualize the DAG, and how to manipulate it safely.

What Is Git’s DAG?

Git stores your project’s history as a Directed Acyclic Graph where commits are nodes and parent relationships are edges. Let’s break down what this actually means and why it matters.

What Makes It a DAG?

A Directed Acyclic Graph has three defining properties: direction (edges point from child to parent), no cycles (you can’t follow parent pointers back to a commit you’ve already visited), and connectivity (every commit except the initial one has at least one parent). These aren’t just mathematical trivia — they fundamentally shape how Git works.

The direction of edges means there’s always a clear “backward” path from any commit to the beginning of history. When you run git log, Git follows these parent pointers backward, showing you increasingly older commits. The absence of cycles guarantees this process terminates. And connectivity ensures every commit is traceable back to the project’s origin.

Consider what happens when you create a merge commit with two parents. Git stores this as a single node with two edges pointing backward, one to each parent. The graph structure makes parallel development natural and explicit.

Git’s Object Storage

Git implements this DAG using four core object types: blobs (file contents), trees (directory listings), commits (snapshots with metadata), and tags (pointers to commits). Each commit object contains a SHA-1 hash, the tree hash, parent commit hashes, timestamps, and the commit message.

The hash uniquely identifies the commit based on its content — if anything changes, the hash changes. This content-addressable storage means Git can detect corruption and guarantee integrity. Here’s what a commit object looks like internally:

tree 3a4b5c6d7e8f0g1h2i3j4k5l6m7n8o9p0q1r2s
parent 9z8y7x6w5v4u3t2s1r0q9o8n7m6l5k4j3i2h1g
author Jane Developer <jane@example.com> 1735689600 +0000
committer Jane Developer <jane@example.com> 1735689600 +0000

Add user authentication feature

The parent reference creates the edge in our DAG. This is why Git’s history is immutable — you can’t change a commit’s parent without changing its hash, which would require updating all descendant commits.

References, Branches, and HEAD

References are human-readable names that point to commits. The most common reference is a branch, which is simply a movable pointer to a commit. When you create a branch with git branch feature-x, Git creates a file at .git/refs/heads/feature-x containing the SHA-1 hash of the current commit.

HEAD is a special reference that points to the branch you’re currently working on. When you make a new commit, Git updates the branch HEAD points to, moving the branch reference forward. This design explains why branching in Git is instant and cheap — creating a branch just means writing a 41-byte file containing a commit hash.

Other important references include:

• Remote-tracking branches (refs/remotes/origin/main) track remote branches

• Tags point to specific commits and don’t move

• The reflog records every position HEAD has occupied

• Stashes are commits pointed to by special refs

When you delete a branch with git branch -d, Git checks whether the branch’s commits are reachable from another reference. If not, it warns you. These commits still exist in the object database until garbage collection, but they’re no longer accessible through normal references.

Visualizing the Graph

The most basic visualization is git log --graph --oneline --all, which shows commits as nodes with lines connecting them:

* a1b2c3d (HEAD -> main) Fix critical bug
| * e5f6g7h (feature-x) Add new feature
|/
* d4e5f6g Initial commit

When reading the graph, look for important patterns:

• Linear chains represent sequential development

• Merge commits have multiple parents (two lines converging)

• Branch points occur where divergent commits share a parent

• Orphaned commits with no path from HEAD will be garbage collected

More sophisticated tools like gitk, tig, or GitKraken make these patterns even more explicit.

Safe vs. Dangerous Operations

The key to working confidently with Git is understanding which operations rewrite history and which only add new commits.

Safe Operations (Add New Commits)

Any operation that adds new commits without changing existing ones is safe, even for shared history. Merging is the canonical example:

git checkout main
git merge feature-branch

This creates a new commit with two parents. No existing commits are modified, so this is safe even if others have based work on main.

Cherry-picking also creates new commits rather than modifying existing ones:

git cherry-pick abc1234

Git creates a new commit containing the same changes but with a different hash (different parent, different timestamp). The original commit remains untouched.

Dangerous Operations (Rewrite History)

Rebasing rewrites history by creating new commits and abandoning old ones. This is powerful but dangerous for shared history:

git checkout feature-branch
git rebase main

This finds the merge base between feature-branch and main, then recreates each commit with main as the new parent. Anyone who built work on the original commits will need to reconcile — the old commits still exist in the reflog, but they’re no longer referenced by a branch name.

Interactive rebasing gives you surgical control:

git rebase -i HEAD~5

This opens an editor showing the last five commits, letting you reorder, squash, edit, or drop them. Each action rewrites history.

Recovery: The Reflog Is Your Safety Net

When things go wrong, the reflog records every position HEAD has occupied — including commits you’ve “lost” through rebasing or branch deletion:

# Show everywhere HEAD has been
git reflog

# Restore to a previous state
git reset --hard HEAD@{5}

Git garbage collection won’t remove commits still in the reflog, giving you a window to recover mistakes. Before panicking about lost work, always check the reflog first.

Detached HEAD state occurs when HEAD points directly to a commit rather than a branch reference. Any commits you create in this state aren’t referenced by a branch name and can be lost if you switch away. To preserve them:

git checkout -b rescue-branch

Key Takeaways

• Git stores history as a DAG where commits are nodes and parent references are directed edges. This structure provides integrity, enables efficient operations, and makes parallel development explicit.

• References are movable pointers to commits. Branches are simply references, and HEAD is a special reference pointing to your current location. Understanding this clarifies branch operations and detached HEAD.

• Safe operations add new commits without modifying existing ones. Merging, cherry-picking, and branching are safe even for shared history because they only extend the graph.

• Rebasing rewrites history by creating new commits. Use rebase on local feature branches; avoid it on public branches others have based work on.

• The reflog provides recovery from mistakes. Every position HEAD occupies is recorded. Before panicking about lost work, check the reflog.

Git’s DAG structure isn’t just an implementation detail — it’s the foundation for everything Git does. Next time you encounter a merge conflict, a confusing rebase, or an unexpected Git state, visualize the graph. Ask yourself: what does the graph look like right now? What references point where? What operation will produce the structure I want? This mental model will serve you through every Git challenge you face.