Git History and Recovery: Rebase, Amend, Cherry-Pick, and Reflog

As your Git skills grow, you eventually need to answer hard questions: can I clean up this commit history, and can I recover work after a mistake? This post gives you practical tools for both.

Table of Contents

This post focuses on safe history editing and recovery workflows.

History Inspection

History Editing

Recovery

Series Navigation

History inspection

Read history with intent

Instead of reading commits as a long list, filter by scope:

# compact history
git log --oneline --decorate --graph

# only one file
git log -- path/to/file

# commits by one author in a date range
git log --author="Alice" --since="2026-05-01" --until="2026-05-31"

When you are diagnosing behavior changes, filtered logs are faster than scrolling through everything.

Inspect one commit deeply

Show a single commit with patch:

git show <commit-sha>

See line-level authorship context:

git blame path/to/file

Use blame as a debugging tool, not a blame-culture tool. The goal is context, not finger-pointing.

History editing

Amend the most recent commit

Forgot a file or typo in your last commit message? Amend it:

# include additional staged changes in the latest commit
git add path/to/missed-file
git commit --amend

This rewrites commit identity (new SHA), so avoid amending commits that are already shared unless your team explicitly agrees.

Interactive rebase for cleanup

Interactive rebase lets you reorder, squash, reword, or drop recent commits before review/merge.

git rebase -i HEAD~4

Example todo list:

pick a1b2c3d Add API endpoint
pick b2c3d4e Fix typo in endpoint docs
pick c3d4e5f Add endpoint tests
pick d4e5f6a Remove debug logging

You can change commands to reword, squash, or fixup for a cleaner review story.

If a conflict happens during rebase:

# resolve files manually, then:
git add <resolved-files>
git rebase --continue

# or stop and return to previous state:
git rebase --abort

Golden rule: rewrite only commits that have not been consumed by shared branches.

Cherry-pick targeted commits

cherry-pick applies one commit from somewhere else onto your current branch.

git switch release/1.4
git cherry-pick <commit-sha>

This is useful for backporting a bug fix without merging an entire feature branch.

Recovery

Use reflog as your safety net

Reflog records where HEAD and branch refs have pointed recently, even after resets or rebases.

git reflog

If you lost a commit after a bad reset, find a prior ref from reflog and recover:

git switch -c rescue-work <reflog-sha>

Create a rescue branch first, then decide whether to merge or cherry-pick recovered commits.

Reset vs restore mental model

git restore adjusts file content in working tree/index. git reset changes branch/ref history and staging behavior.

Common safe usage:

# unstage without losing file edits
git reset HEAD path/to/file

# move current branch pointer back one commit, keep file edits
git reset --soft HEAD~1

Use git reset --hard with extreme care because it discards uncommitted changes in tracked files.

Practical safety habits

  • Create a temporary branch before risky history edits
  • Run git status before and after each recovery step
  • Prefer small rebases over giant cleanup sessions
  • Use descriptive commit messages so later history surgery is easier

Next in this series

In the final post, we cover advanced team patterns: trunk-based vs long-lived branches, bisect for regressions, worktrees for parallel development, and lightweight hooks