If Git shows HEAD detached, your files are still checked out at a commit, but new commits won’t advance a branch until you create one. On a Mac, open Terminal, go to the repository, check for uncommitted edits, and then either attach your current work to a new branch or safely return to the branch you meant to use. Git’s switch command supports both paths. Apple’s Terminal guide explains how to open Terminal; Git’s switch documentation documents branch and detached-HEAD behavior.

1. Check what Git has checked out

Open Terminal from Applications > Utilities, then change to your repository. Replace the example path with the folder where your project lives; quotes allow spaces in the path. macOS Terminal uses zsh by default, and these commands work in zsh as well as common shells.

cd "/path/to/your/repository"
git status

If git status says “HEAD detached” or “not on any branch,” you are in detached HEAD state. Git has checked out a commit directly instead of a branch. The commit and working files remain available; the risk is that commits made here are not automatically attached to a branch. Git’s checkout manual describes this state and how a branch can preserve commits made there.

Before switching anywhere, read the rest of git status. If it lists modified or untracked files, those are changes that have not been committed. You can keep working in place, or make a branch now; creating a branch at the current commit does not itself discard edits. Avoid force or discard options while recovering.

2. Keep the current work on a branch

If you made a commit while detached—or want to continue working from this exact snapshot—create a branch where you are now:

git switch -c recovered-work
git status

Use a descriptive branch name in place of recovered-work. Git creates the branch at the current commit and switches to it, so later commits belong to that branch. Confirm that git status now names the branch. This is the shortest recovery when the detached snapshot is the work you want to keep. Git documents switch -c as creating and switching to a branch.

If you have uncommitted edits, they ordinarily remain in the working tree as you create the branch. Check git status afterward to verify they are still present. If the command refuses because a branch with that name already exists, choose a different name; do not add -C, which can reset an existing branch to a new starting point.

3. Return to the branch you intended to use

If you only inspected a commit and have no changes to preserve, switch to the intended branch by name. For example:

git switch main

Use your repository’s actual branch name if it is not main. If Git reports that local changes would be overwritten, stop and preserve them first: create a recovery branch as above, or commit the work. Git normally blocks a branch switch when it would lose local modifications; avoid --discard-changes during recovery because it resets the index and working tree to match the target branch. The git switch manual explains these safeguards and options.

If you just switched away from a branch by mistake, git switch - returns to the previous branch or commit recorded by Git’s recent switch history. Check git status after the switch to confirm where you landed.

4. Find a detached commit you left earlier

If you already switched away and cannot remember where your detached commit went, inspect the local reflog:

git reflog

The reflog records recent local reference updates, and the HEAD reflog also records branch switching. Look for an entry with a commit message or time that matches your work. To inspect a candidate without changing anything, copy its short commit ID from the reflog and run:

git show --stat COMMIT_ID

Replace COMMIT_ID with the actual ID—do not type the placeholder literally. If it is the right commit, preserve it by creating a branch at that commit:

git switch -c recovered-work COMMIT_ID

This makes the commit reachable by a branch again. Reflogs are local records, and entries can expire; Git’s documentation describes them as records of recent reference updates and notes their expiration behavior. See git reflog.

5. Verify before continuing

Run git status and git log -1 --oneline to confirm the current branch and latest commit. If your work was uncommitted, check that its files still appear in the status output. If no candidate appears in the reflog, recovery may require examining dangling objects; that is a separate, more careful step, and you should avoid running cleanup commands such as git gc while searching.

A detached HEAD does not mean your work vanished. The right recovery depends on whether you need to preserve the current commit, return to an existing branch, or locate a commit after switching away. A branch created at the correct commit gives Git a named reference to follow as you continue.

Sources