To check whether a local Git branch is safe to delete on macOS, inspect your working tree, compare the branch’s commits with the branch you intend to keep, and check whether it is in use in another worktree. Open Terminal, change to the repository, and use Git’s merged-branch check as evidence—not as a guarantee that the branch has no value. If you are unsure, keep the branch until you confirm its work is preserved.

1. Open the repository and check for unfinished changes

Open Terminal from Applications > Utilities, or use Spotlight to find it. Apple documents zsh as Terminal’s default shell, and the commands below work in the standard macOS setup. In Terminal, move to the repository directory; quote the path if it contains spaces:

cd "/path/to/your/repository"
git status --short --branch

The status output shows the checked-out branch and whether files have changes. Commit or otherwise preserve wanted file changes before changing branches. This check is separate from branch history: a clean working tree does not mean the branch’s commits have been merged. Likewise, uncommitted changes are not protected just because you delete a branch with Git’s normal safe-delete option.

2. Check whether the branch is merged into the right target

First identify the branch you intend to keep, commonly main or develop. If you are currently on the candidate branch, switch to the target branch before deleting anything. Replace feature/example and main below with your actual branch names:

git switch main
git branch --merged main
git branch --no-merged main

The first list contains local branches whose tips are reachable from main; the second lists branches whose tips are not. Git describes git branch --merged as listing branches merged into the specified commit (or HEAD if none is supplied). This is a commit-history test, so it is useful only when main is the branch that should contain the work. A branch merged into another release or integration branch may still appear unmerged against main. Git branch documentation

If the candidate appears in --merged main, that is a strong indication its commits are already reachable from main. Confirm the feature or fix is present where expected, especially if your team uses pull requests, release branches, or a different merge target. If it appears under --no-merged, don’t delete it until you have inspected what commits are unique to it.

3. Inspect commits and upstream tracking

To compare a candidate with the target, use:

git log --oneline main..feature/example

This shows commits reachable from feature/example that are not reachable from main. If it prints commits, inspect them and decide whether they need to be merged, cherry-picked, or kept. An empty result means the candidate has no commits beyond main in this comparison; it does not establish that the branch name or its purpose is no longer needed.

A branch may also track a remote branch. Check its tracking information with:

git branch -vv

An upstream is a configured reference used by Git for operations such as pull and push. A missing or gone upstream does not prove the local branch is safe to remove: its commits may still be unique. Also, a remote-tracking reference can be stale until you fetch. If you want to refresh remote-tracking data, git fetch --prune origin fetches from origin and removes stale remote-tracking references according to that remote’s refspec; it does not delete your local branch. Git fetch documentation

4. Check worktrees, then delete safely

A branch can be checked out in another linked worktree. Git refuses to delete a branch that is checked out, so if deletion is refused, check git worktree list and inspect the listed directories before taking further action. Also verify that the candidate is not your current branch; switch to the intended target first. Git branch documentation

When you have confirmed the work is preserved and the branch is no longer needed, delete it using Git’s guarded option:

git branch -d feature/example

Git allows -d only when the branch is fully merged into its configured upstream, or into HEAD when no upstream is configured. If Git refuses, treat that as a prompt to investigate. -D forces deletion regardless of merge status; it bypasses this safeguard and should not be a routine workaround. Git branch documentation

A cautious decision is straightforward: delete with -d only after the candidate’s work is present in the intended destination, unique commits have been reviewed, and no worktree still uses the branch. If any of those checks is unclear, keep the branch and clarify its destination first.

Sources