How can I view the history of changes to one file in Git?
Quick answer
From your repository, run git log -- path/to/file to list commits affecting that path. Add -p to display patches for those commits: git log -p -- path/to/file. If the file may have been renamed, try git log -p --follow -- path/to/file. --follow applies to one file, and path changes or rename detection can affect which earlier commits appear. [S1]
The question, the details, the next step.
I’m in a Git repository and want to see only the commits that changed one file. What should I run?
Use a path-limited log, putting -- before the file path:
git log -- path/to/file
For example, if the file is src/report.py, run git log -- src/report.py. The path limitation narrows the history to commits affecting that path. [S1] Replace the example with the path for your file. The command lists commit information; it does not, by itself, show the full patch for each change.
How do I see what actually changed, and then focus on one of the commits?
Add -p to display patches for the commits in the file’s history:
git log -p -- src/report.py
Read through the output until you reach the commit you’re interested in; the patch shown with that entry lets you inspect its changes. Git log options can display patches for the listed commits. [S1]
For instance, if the output includes several commits affecting src/report.py, find the relevant commit entry and review its patch. This keeps the investigation tied to the file rather than showing patches for every commit in the repository.
The file was renamed. How can I look further back, and what should I expect?
Try --follow to continue the history of a single file beyond a rename:
git log --follow -- path/to/file
Add -p if you want to see patches as well:
git log -p --follow -- path/to/file
The documented scope of --follow is one file. A path-limited log without it may not show the full history across a rename, and path changes or rename detection can affect what appears. [S1] Treat the result as history Git can trace for that path, rather than proof that every earlier version has been found. If an expected change is missing, consider whether the file had a different path earlier.
Could you give me a small example workflow I can reuse when I’m investigating a file?
Assuming the file’s current path is docs/setup.md, you could use this workflow:
- List commits affecting that path:
git log -- docs/setup.md. - Display their patches:
git log -p -- docs/setup.md. - Find the commit entry you want to inspect and review its associated patch.
- If the file may have been renamed, try
git log -p --follow -- docs/setup.mdto look across a detected rename.
Replace docs/setup.md with the path you’re investigating. The path-limited history focuses on commits affecting that path, while --follow can continue the history of a single file beyond renames. [S1] Neither the path nor rename detection guarantees that every earlier change will appear, so check for earlier paths if the output seems incomplete.
A practical checklist
Run the command in the repository whose history you want to inspect.
Put the file path after
--to limit the log.Add
-pto display the changes for listed commits.Try
--followif a single file may have been renamed.If expected history is missing, consider whether the file had an earlier path.
A few more useful answers
What does `--` do in `git log -- path/to/file`?
It marks the path limitation after the log options, so the command narrows the history to commits affecting that path. [S1]
Does `--follow` guarantee that I’ll see every version of a file?
No. It can continue a single file’s history beyond renames, but path changes and rename detection can affect what appears. [S1]
Sources
References used for this guide.
- [S1] Git - git-log Documentation git-scm.com · Checked