Introduction

Git can show the full history of a single file, including which commits changed it, what the diffs were, and who last touched specific lines. The most useful commands are git log for commit history, git log -p for patches, and git blame for line-level attribution.

See the Commit History for One File

The basic command is:

git log -- path/to/file

The -- separator matters because it tells Git that what follows is a path, not another revision or option. This command lists commits that affected that file.

You can also make the output easier to scan:

git log --oneline -- path/to/file

That is often the fastest way to answer, "Which commits touched this file recently?"

Show the Actual Diffs

If you want to see what changed in each commit, add -p.

git log -p -- path/to/file

This includes the patch for every matching commit. It is useful when you are debugging a regression or trying to understand when a specific line was introduced.

If the file is large, add a limit:

git log -p -n 5 -- path/to/file

That keeps the output focused on the most recent changes.

Follow Renames

By default, file history can become confusing after a rename. Use --follow if the path changed over time.

git log --follow -- path/to/file

This is especially important for long-lived files that have been reorganized between directories or renamed during refactors.

You can combine it with patches:

git log --follow -p -- path/to/file

Use git blame for Line History

When you care about who last changed each line rather than the file as a whole, use git blame.

git blame path/to/file

This prints each line with the commit hash, author, and timestamp of the last commit that modified it. It is useful for tracing ownership and understanding the most recent editor of a specific section.

For a smaller range, use line boundaries:

git blame -L 20,40 path/to/file

That keeps the result focused on the portion you are investigating.

Inspect One Commit in Detail

Once git log reveals the commit hash you care about, open that change directly.

git show abc123 -- path/to/file

This is often a cleaner workflow than scanning a huge log with patches included for every commit.

A common sequence is:

1. use git log --oneline -- path/to/file
2. pick a commit hash
3. inspect with git show
4. use git blame if you need line-level context

Practical Notes

History inspection becomes more accurate when commits are small and descriptive. If a file was reformatted wholesale, git blame and patch history can become noisy. In that case, pairing git blame with commit messages and surrounding diffs gives a better picture than trusting one command alone.

Also note that git log shows commits that affected the file path, not a semantic history of ideas. Large moves, code generation, or aggressive refactors can make the output noisier than expected.

Common Pitfalls

• Forgetting the -- path separator can make Git interpret the filename as something other than a path. Use it consistently with git log and related commands.
• Using git log without --follow on a renamed file can hide older history. Add --follow when the path changed.
• Expecting git blame to show original authorship through major refactors can be misleading. It shows the last modifying commit for each current line.
• Reading every patch in a long history with git log -p can overwhelm the investigation. Start with --oneline and drill down into the specific commits that matter.
• Assuming history commands explain intent on their own misses important context. Commit messages and code review discussion still matter.

Summary

• Use git log -- path/to/file to see file-level commit history.
• Add -p when you need the diffs and --follow when the file was renamed.
• Use git blame to inspect who last changed specific lines.
• 'git show <commit> -- path/to/file is useful once you find the commit you care about.'
• The best workflow is usually a combination of log, show, and blame rather than relying on one command alone.