Module 2: Precision History Inspection

Log Recipes for Real Investigations

Module: Module 2: Precision History Inspection

git log is not one command; it is a query tool. With formatting, path filters, date filters, graph output, and ancestry options, it can answer narrow questions about how a repository evolved.

Start with compact history when orienting yourself, then add detail only when needed. For example, --oneline --graph --decorate shows topology and branch labels. --stat shows the files touched by each commit. --patch shows the actual diff. Path filters let you focus on one subsystem without leaving the command line.

Good history investigation is hypothesis-driven. Ask a concrete question: when was this file introduced, which release branch has the fix, or which commits touched this function? Then choose log options that answer that question with the least noise.

Command Walkthrough

git log --oneline --decorate --graph --all
git log --stat -- app.conf
git log --since='2 weeks ago' --author='Your Name'
git log --first-parent main
git log --merges --oneline
git show --name-status HEAD

Representative output

commit d4e5f6a7b8c9
Author: Alex Engineer <[email protected]>

    Add focused change

 app.conf | 2 +-

Hands-on Lab

In the practice project, create three commits touching README.md, app.conf, and CHANGELOG.md. Use git log to answer which commits touched only app.conf and which commits are on the feature branch but not main.

What to Watch For

A visually simple log can hide merges. Use --graph when topology matters.
Path-limited history can simplify merges and omit context. It is useful, not absolute truth.
First-parent history is great for release narratives but not for finding every implementation commit.

Completion Check

You should be able to explain what each command changed, inspect the resulting history, and describe how you would undo or recover from the operation before using it in a shared repository.