To find the commit that last changed a line in a local Git project on your Mac, open Terminal, move into the repository, and run git blame on the file with the line number range. Then inspect that commit with git show to read its message and diff. Blame identifies the last change to the current line; it does not always reveal when the line first appeared or why it was written.

1. Open the repository in Terminal

If you already have the project open in Finder, open Terminal and type cd , then drag the project folder into the Terminal window and press Return. macOS will insert the folder’s path; this avoids mistyping it. Alternatively, enter the path yourself and quote it if it contains spaces, for example:

cd "/Users/sam/Projects/My App"

Check that you are inside a Git working tree and that Git is available:

git status --short
git --version

If the first command reports that the current directory is not a Git repository, navigate into the project’s actual repository directory. If git is unavailable, install or enable Git through a setup you trust before continuing. The commands below use standard shell syntax and work in macOS Terminal’s default shell as well as other common shells.

2. Run blame for the line you care about

Find the line number in your editor, then substitute the file path and line number below. The path is relative to the repository root; quote it when it contains spaces or shell metacharacters.

git blame -L 42,42 -- "Sources/Settings.swift"

-L 42,42 restricts the annotation to line 42. Git counts lines starting at 1. To inspect surrounding context, use a range such as -L 38,46. Git prints a commit identifier, author details, date information, and the line’s text. Its documentation describes blame as showing the revision and author that last modified each line, and supports selecting line ranges with -L. Git blame documentation

If you do not know the line number, open the file in your editor and use its displayed line numbers. You can also blame the whole file by leaving off -L:

git blame -- "Sources/Settings.swift"

When you are not at the repository root, use a path relative to the directory where you ran the command. If Git says the path does not exist, check both your current directory (pwd) and the exact capitalization and spelling of the path.

3. Read the commit that blame identifies

Copy the commit identifier shown for the target line and pass it to git show:

git show --format=fuller --stat a1b2c3d

Replace a1b2c3d with the identifier from your output. This displays commit metadata and a file summary. To read the patch as well, omit --stat:

git show --format=fuller a1b2c3d

Look at the changed lines around the target line, the commit message, and the other files changed in the same commit. These details can help explain the change’s context. A commit message records what its author wrote; it is not proof of the design rationale. Git documents git show as displaying commit information and its textual diff. Git show documentation

When blame points to a formatting or move commit

A line may have been touched by a broad formatting pass, rename, or code move. In that case, the blamed commit may not be the one that originally introduced the logic. Try move and copy detection:

git blame -M -C -L 42,42 -- "Sources/Settings.swift"

-M asks Git to detect lines moved within a file, while -C also looks for lines copied or moved from other files. These options help Git trace some refactors, but detection depends on matching content and may not resolve every history. Git blame documentation

If a repository has a .git-blame-ignore-revs file for broad changes such as formatting, you can ask Git to use it:

git blame --ignore-revs-file .git-blame-ignore-revs -L 42,42 -- "Sources/Settings.swift"

This can make the relevant change easier to spot, but ignored revisions affect the annotation; inspect the repository’s ignore file or compare with a blame run without that option if the result seems surprising. The Git documentation lists this option, and GitHub documents the same ignore-revisions file convention. Git blame documentation

What blame cannot tell you

Blame annotates lines that exist in the selected file version. It does not directly show deleted or replaced lines, and the most recent modifying commit can differ from the original introduction. For deleted text or earlier file states, inspect commit diffs and history; Git’s blame documentation points to git diff and history searches for changes that removed or replaced content. Git blame documentation

If the repository is hosted on GitHub and you have access to it, you can also open the file and select Blame to see line-by-line history in the browser. Click a commit message to inspect that change, or use the versions control to view the file before it. GitHub Docs: Viewing and understanding files

Sources