🕰️ History Management and Navigation

History as a Tool

Most beginners treat Git history as a passive receipt — proof that they saved their work. But history is far more valuable than that. It records who changed what, when, and (if you write good messages) why. Learn to query it and you can answer questions like "when did this function stop working?", "who wrote this odd line and what were they thinking?", and "how do I get back the branch I deleted an hour ago?"

💡 Reframe it: Git isn't a backup drive, it's a database of your project's evolution — and git log is the query language. The rest of this lesson teaches you to read, search, travel through, and repair that database.

Exploring with git log

Plain git log lists commits newest-first with hash, author, date, and message. In a real repository that's a firehose, so the skill is filtering.

Shaping the output

git log -n 5              # only the 5 most recent
git log --oneline         # one compact line per commit
git log --graph           # ASCII branch/merge graph
git log --stat            # files changed + insertion/deletion counts
git log -p                # full patch (the actual diff) per commit

# A comprehensive, all-branch overview
git log --oneline --graph --all --decorate

Filtering to find exactly what you need

These compose. To see Ray's changes to the components folder in the last month:

git log --author="Ray" --since="last month" -- src/components/

Custom formats and aliases

You can shape each line precisely with --pretty=format: and save frequent commands as aliases:

# Hash · relative date · subject · refs · author
git log --pretty=format:"%h %ar %s%d [%an]"

# Save it as a reusable alias:  git lg
git config --global alias.lg "log --graph --oneline --decorate --all"

Common format specifiers: %h short hash, %an author name, %ar relative date, %s subject, %d ref names.

Referencing & Navigating Commits

To travel to a point in history you first need a way to name it. Git gives you several.

With HEAD at commit F in the graph above:

The distinction matters at merges: ~ walks back generations along the first parent, while ^N selects which parent of a single commit. You can also reference by hash (git show a1b2c3d), by name (git show v1.0.0), or even by time (git show main@{yesterday}).

Checking out the past

# Look around a historical commit (detached HEAD)
git switch --detach a1b2c3d      # or: git checkout a1b2c3d

# Branch off a historical commit to build on it
git switch -c fix-old-bug a1b2c3d

# Pull just ONE file from a past commit into your working tree
git restore --source a1b2c3d -- path/to/file.js   # modern
git checkout a1b2c3d -- path/to/file.js           # classic equivalent

Comparing points in time

git diff a1b2c3d..d4e5f6a     # changes between two commits
git diff main..feature        # changes between two branches
git show a1b2c3d              # one commit's message + diff

Finding Bugs: bisect & blame

Two commands turn history into a debugging superpower.

git blame — who wrote this line, and when?

git blame path/to/file.js

For each line, blame shows the commit, author, and date that last changed it — the fastest way to find the context (and the commit message) behind a puzzling line before you touch it.

git bisect — binary-search for the breaking commit

Suppose something works in an old version but is broken now, and hundreds of commits sit between. Testing each one is hopeless. bisect does a binary search: mark one good and one bad commit and Git repeatedly checks out the midpoint for you to test, halving the search each round.

git bisect start
git bisect bad                 # current commit is broken
git bisect good v1.2.0         # this old tag worked

# Git checks out a midpoint. Test it, then tell Git:
git bisect good                # ...if this one works
git bisect bad                 # ...or if it's broken
# Repeat until Git names the first bad commit, then:
git bisect reset               # return to where you started

Over 1,000 commits, bisect finds the culprit in about 10 tests instead of 1,000. If you have a script that exits non-zero when broken, git bisect run ./test.sh automates the whole hunt.

Rewriting History Safely

Sometimes you need to fix history before sharing it: a typo in a message, a forgotten file, or five scratch commits that should be one. Git can rewrite history — but remember the golden rule from the last lesson: only rewrite commits you haven't shared.

Amending the last commit

# Fix the most recent commit message
git commit --amend -m "Correct, clearer message"

# Add a file you forgot, keeping the same message
git add forgotten-file.js
git commit --amend --no-edit

--amend doesn't edit the old commit — it replaces it with a new one, so never amend something already pushed to a shared branch.

Interactive rebase for deeper cleanup

git rebase -i HEAD~5   # curate the last 5 commits

In the editor you can reword messages, squash/fixup related commits together, drop commits, reorder lines to reorder commits, or edit a commit to stop and change its content:

# Squash three commits into one clean commit:
pick   abc1234 Add login form
squash def5678 Fix typo in form
squash ghi9012 Adjust form styling

If you must touch shared history

• Communicate with the team first so no one is mid-work on it.
• Push with git push --force-with-lease, never bare --force — it refuses if someone else has pushed, protecting their work.
• Prefer creating a new branch with the cleaned history over rewriting the shared one.

Recovery with the Reflog

Here's the reassuring truth that makes Git safe to experiment with: it's very hard to truly lose committed work. Git records every position HEAD has occupied in the reflog, even commits no branch points to anymore. That's your safety net.

git reflog             # every place HEAD has been, most recent first
git reflog show main   # the reflog for a specific branch

Common rescues

# Undo a hard reset that "lost" commits
git reflog                       # find the hash from before the reset
git switch -c recovery a1b2c3d   # rebuild a branch at that commit

# Recover a branch you deleted before merging
git reflog                       # locate its last commit
git switch -c recovered-branch a1b2c3d

# Restore a file deleted in an earlier commit
git log --diff-filter=D --summary            # find the deleting commit
git checkout a1b2c3d^ -- path/to/deleted.js  # ^ = the commit BEFORE deletion

Tags & Releases

Tags mark meaningful points in history — almost always releases. Unlike branches, a tag never moves once created.

# Lightweight tag — just a name for a commit
git tag v1.0.0

# Annotated tag — carries a message, author, and date (use for releases)
git tag -a v1.0.0 -m "First stable release"

git tag                     # list tags
git show v1.0.0             # inspect a tag and its commit

# Tags are NOT pushed automatically:
git push origin v1.0.0      # push one tag
git push origin --tags      # push all tags

Pair tags with Semantic Versioning — MAJOR.MINOR.PATCH — so the number itself communicates the change:

• MAJOR — incompatible/breaking changes
• MINOR — new, backward-compatible functionality
• PATCH — backward-compatible bug fixes

On platforms like GitHub, pushing a tag lets you attach formal Releases — release notes and downloadable binaries built on top of that tagged commit.

Hands-on Exercise

mkdir reflog-demo && cd reflog-demo
git init -b main
echo "line 1" > notes.txt
git add notes.txt && git commit -m "First commit"
echo "line 2" >> notes.txt
git commit -am "Second commit (about to be lost)"

git reset --hard HEAD~1        # second commit gone from the branch
git log --oneline             # only 'First commit' remains

git reflog                    # spot: HEAD@{1} ... Second commit
git switch -c recovered HEAD@{1}
git log --oneline             # 'Second commit' is back on 'recovered'

Summary & Quiz

📚 Further Reading

• Pro Git — Viewing the Commit History
• Pro Git — Revision Selection
• git bisect documentation
• Semantic Versioning Specification
• git-filter-repo (rewriting history at scale)

🚀 What's Next?

You've mastered Git locally — branching, integrating, and navigating history. Next we move from your machine to the wider world: the GitHub platform, where repositories become collaborative and your work meets the rest of the team.