If Git keeps listing a file even though it matches .gitignore, remove it from Git’s index while leaving the local copy in place. In Terminal, go to the repository, run git rm --cached -- "path/to/file", then commit that staged removal and the ignore rule. Git’s documentation confirms that ignore rules affect untracked files; they do not stop tracking files already in the index. (Git gitignore documentation)

Why .gitignore has not stopped tracking the file

A .gitignore pattern tells Git to leave matching untracked paths alone. If a file was already added to the repository, Git continues to track changes to it regardless of a later ignore rule. The rule can be correct and still appear to have no effect until you remove that file from the index. (Git gitignore documentation)

On Mac, open Terminal and change to the repository’s top-level folder. Apple documents Terminal as macOS’s command-line interface and identifies zsh as the default shell; the commands below work in the usual zsh setup. Confirm you are in the right repository before changing its index:

git status

The file path in the next command is relative to the repository root. Replace the example with the actual path. Keep the quotes: they protect spaces and characters such as * from being interpreted by the shell. The -- marks the end of options, so a path beginning with a hyphen is treated as a path.

Remove the file from the index and keep the Mac copy

Run:

git rm --cached -- "path/to/file"

--cached removes the path from Git’s index, not from the working tree. The file should remain on your Mac. This stages a removal for the next commit; it does not erase the file’s earlier committed history. (Git git rm documentation)

If the path is inside a directory and you mean to stop tracking the whole directory, add -r and use its path:

git rm --cached -r -- "path/to/directory"

Use this carefully: Git removes all tracked paths under that directory from the index. The local files remain, but the removal is staged. If Git refuses because the file has staged changes or its contents differ from the version in the latest commit, stop and inspect git status; do not add -f unless you understand which staged changes would be discarded. Git documents force as an override to its normal protection for such changes. (Git git rm documentation)

Check the ignore rule and review what will be committed

Make sure the .gitignore pattern matches the path from the location of that ignore file. For example, a rule in the repository-root .gitignore containing local-settings.json matches files with that name at any directory level; /local-settings.json restricts the match to the repository root. Git patterns are relative to the directory containing the .gitignore, and more specific lower-level ignore files can affect the result. (Git gitignore documentation)

Ask Git which rule matches the now-untracked file:

git check-ignore -v -- "path/to/file"

The -v option shows the source and pattern responsible. If this prints nothing, recheck the spelling, path, and pattern location. Git’s FAQ recommends git rm --cached plus a matching ignore pattern to untrack and ignore an already tracked file. (Git FAQ)

Review the staged change and working copy before committing:

git status

The status should show the path staged as deleted and .gitignore as modified if its change is not already staged. The working file should still be present. Stage the ignore file if needed, then commit both changes:

git add -- .gitignore
git commit -m "Stop tracking local file"

If the relevant ignore file is in a subdirectory, use its repository-relative path in git add. Review git status again before committing, especially if other work is staged, so the commit contains only the changes you intend.

What happens after the commit

After the commit, Git no longer tracks that path in the current branch, and the ignore rule prevents it from being added again accidentally. The commit records a removal, so collaborators who check out that commit will see the tracked file removed from their working tree; each person’s local ignored copy is not automatically preserved by Git. Coordinate before committing if the file contains shared configuration that teammates still need. Previously committed versions remain in repository history, so this procedure does not remove past copies. (Git git rm documentation)

If you intended only to hide local edits while keeping the file tracked for everyone, .gitignore is not the right mechanism. Git advises against using assume-unchanged or skip-worktree for that purpose; consider a tracked template and a separate ignored local configuration file instead. (Git FAQ)

Sources