Skip to content

Deleting and Renaming Branches

A branch is a movable reference to a Commit, not a separate copy of the project. Renaming or deleting that reference changes how you reach a Commit by name; it does not rewrite the Commit or immediately erase its files.

Suppose master and rename-lab both point to C2:

HEAD → master ─────┐
C2 → C1
rename-lab ─┘

Renaming rename-lab changes only its reference name. Its Commit ID remains C2, and HEAD stays on master. Deleting rename-lab removes that name, while master still reaches C2.

In a disposable repository, first inspect the current state and existing names:

Terminal window
git status --short
git branch --list rename-lab renamed-lab
git branch rename-lab
git branch -v
git branch -m rename-lab renamed-lab
git branch -v

git branch <name> creates a branch at the current Commit without switching to it. git branch -v lists each local branch with its short Commit ID and subject; * marks the current branch. git branch -m <old> <new> renames a branch without changing its tip. To rename the currently checked-out branch, git branch -m <new> is enough. Check the intended names before renaming, especially if the branch is shared elsewhere.

In the lab, both master and rename-lab started at 52727a5. After renaming, renamed-lab still pointed to 52727a5, and HEAD stayed on master.

Terminal window
git branch -d renamed-lab
git branch -D other-branch

-d requests safe deletion: Git refuses if the branch tip has not been integrated into the relevant comparison history. For an ordinary local branch without an upstream, that is typically the current HEAD; when an upstream is configured, Git may use that instead. Inspect the graph and Git’s message rather than assuming the current branch is always the comparison target.

-D skips the merged-history safety check. It does not merge work first, and it does not allow deleting a branch that is checked out in the current or another worktree. Use it only after confirming that losing the branch name is intentional and that any unique commits have another durable reference if needed.

In the lab, saved-work pointed to 6bd2c6f, a Commit not reachable from master at 52727a5. git branch -d saved-work refused, so the branch remained. By contrast, renamed-lab and master pointed to the same Commit; git branch -d renamed-lab succeeded. We did not force-delete saved-work.

Deleting a branch removes its reference, not its Commit objects immediately. Commits still reachable through another branch remain easy to find. Unique commits with no remaining reference may temporarily be recoverable through a local reflog, but that is not a guaranteed backup; Git may eventually prune unreachable objects. Save important work under another branch name before deleting its last useful reference.

  • Treating -D as a way to merge: it only bypasses deletion protection.
  • Assuming the branch name master has special local protection. Git protects the checked-out branch, not that spelling.
  • Deleting a branch because its files look unchanged without checking whether it has unique Commits.
  • Relying on an unreachable Commit remaining available indefinitely.
  • Running deletion commands in a working repository before checking the branch list and history.

git branch -m changes a reference name, not its Commit ID. git branch -d guards against dropping an unmerged branch name; -D bypasses that guard but not the checked-out-branch restriction. Deleting a branch does not immediately delete its commits, yet unique work should have another durable reference before you remove its branch.

Two branches point to the same Commit. What changes when one is renamed and then safely deleted?

Only that branch’s name changes and then disappears. The other branch and the Commit remain unchanged.

Why can -d refuse while -D would proceed?

The branch contains a tip not integrated into the relevant comparison history. -D skips that safety check; it does not merge the Commit.