GtGit · Lesson 7 of 8

Reading History Like a Detective

Who wrote this line? When did this bug appear? What changed last week? Git answers all of these — history isn't just backup, it's documentation.

Bash

git log --oneline            # compact history
git log -p index.js          # commits + diffs for one file
git log --author="Ada"       # filter by author
git log --since="2 weeks ago"
git log -S "parseConfig"     # commits that added/removed this string

git show a1b2c3d             # everything about one commit

# Who last touched each line of a file, and in which commit:
git blame src/auth.js

git bisect deserves special mention: it binary-searches history for the commit that introduced a bug. Mark one good commit and one bad commit, and git checks out the midpoint; you test and say good or bad; repeat. A thousand commits is only ~10 tests.

Bash

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

# Git checks out a middle commit. Test your app, then:
git bisect good    # or: git bisect bad
# ...repeat until:
# a1b2c3d is the first bad commit

git bisect reset             # back to where you started

◆ Note
This is why small, working commits matter: bisect can only pinpoint a bug to a commit. If that commit is a 2,000-line 'various fixes', you've found the haystack, not the needle.