If a file in your Mac’s working folder contains text beginning version https://git-lfs.github.com/spec/v1, you are seeing its Git LFS pointer rather than the large file’s contents. In Terminal, go to the repository, make sure Git LFS is installed and initialized, then run git lfs pull. That command downloads LFS objects for the checked-out branch and updates the working files. It can only restore content that is available from the configured remote or already in the local LFS cache. Git LFS FAQ

1. Open the repository in Terminal and confirm the file is a pointer

Open Terminal and change to the repository directory. If you are unsure where the folder is, type cd (including the trailing space), drag the repository folder from Finder into the Terminal window, then press Return. Check that you are in a Git working tree and inspect the file, substituting its actual path:

git status --short
head -n 3 'path/to/file.ext'

A typical pointer contains a version line, an oid sha256: line and a size line. Git LFS stores this small pointer in Git while the actual content lives in LFS storage. Seeing the pointer in a text editor does not mean the editor can retrieve the missing object; recovery is performed through Git LFS. Git LFS overview

2. Install and initialize Git LFS if needed

Check whether the command is available:

git lfs version

If Terminal reports that lfs is not a Git command, install Git LFS using a trusted installation method for your Mac, then open a new Terminal window and check again. The project documents git lfs install as the one-time setup for a user account; run it to configure Git’s LFS filters and hooks:

git lfs install

This setup is distinct from downloading file contents. If LFS was skipped during a clone or checkout, Git LFS’s FAQ specifically recommends running git lfs pull to replace pointers in the working tree. Git LFS FAQ

3. Download and restore the current branch’s files

From the repository directory, run:

git lfs pull

The command fetches LFS content for the current ref from the default remote and checks out the required working-tree files. It is the simplest recovery step for an ordinary clone where the pointer belongs to the branch you have checked out. Wait for the command to finish and read any errors; a pointer remaining afterward means the download or checkout did not complete for that file. Git LFS command reference

If you already fetched the object earlier but the working file still contains a pointer, try:

git lfs checkout -- 'path/to/file.ext'

git lfs checkout uses content available in the local LFS store; it does not download anything. It restores missing files or files containing the matching pointer, and does not overwrite modified files. This makes it useful after a successful fetch, but it cannot recover an object that is neither cached locally nor successfully fetched. git-lfs-checkout manual

4. If the file still shows a pointer

Check whether the expected path is tracked by LFS and whether the repository has a remote configured:

git lfs ls-files
 git remote -v

If git lfs ls-files does not list the file, confirm that the current branch’s committed .gitattributes rules mark its path for LFS. Merely running git lfs track now does not retrieve historical content, and changing tracking rules does not turn an ordinary Git blob into an LFS object. Git LFS notes that files already in a repository require renormalization and a commit to be converted; do not make that repository change just to recover a file. Git LFS FAQ

If the file is listed, confirm you are on the branch containing the desired version and that the configured remote is the repository that stores its LFS objects. For a different configured remote, fetch that remote and then restore from the local cache:

git lfs fetch 'remote-name'
git lfs checkout -- 'path/to/file.ext'

git lfs fetch downloads objects but does not update the working copy; git lfs checkout performs that local update. Fetching the current ref by default uses the default remote, which follows Git’s remote-selection rules. git-lfs-fetch manual

A failed pull may point to a connection, authentication, access, or missing-object problem. Resolve access to the configured Git/LFS server and retry. If the LFS server no longer has the object, the pointer alone cannot reconstruct the original file: ask a repository maintainer whether another branch, backup, clone, or authorized LFS store has it. Avoid replacing the pointer with guessed content or committing it as though it were the restored file.

Confirm the recovery

After a successful pull or checkout, inspect the file again. Its first lines should no longer be the LFS pointer metadata; use the application appropriate for the file type to confirm that the recovered content opens. Check git status --short as well. A content change may be expected if your working copy had the pointer, but review the reported path before staging or committing anything.

Sources