Git Switch: Changing the Current Branch Safely

Intermediate

Switching changes the current checkout state

V431 established branch names as references and V432 established branch lifecycle operations. This lesson owns the state transition that makes one branch current. `git switch <branch>` changes the current branch and updates the working tree and index to match the target branch. It is therefore different from creating or moving a branch name with `git branch`.

git branch --show-current
git rev-parse --symbolic-full-name HEAD
git switch topic
git branch --show-current
git rev-parse --symbolic-full-name HEAD

main is current; topic already exists.?topic is current and the checkout state matches topic.

A clean switch is not the same as a clean repository requirement

Git does not require the index and working tree to be identical to HEAD before every switch. It does require the switch to avoid losing local changes. If the target branch would overwrite local changes, ordinary switching aborts. This distinction matters: “dirty” is not itself the rejection condition; potential loss of local work is.

git status --short
git switch topic
git status --short

The current branch has local changes that do not overlap the target branch’s differing paths.?Git can switch while preserving those changes.

Create and switch transactionally with `-c`

`git switch -c <new-branch> [<start-point>]` creates a branch and switches to it as one transactional operation. The official documentation contrasts this with `git branch <new-branch>` followed by `git switch <new-branch>`: if the switch cannot succeed, the transactional form does not leave the new branch created/reset merely as a side effect.

git switch -c feature
git branch --show-current
git rev-parse --verify feature^{commit}

The requested new branch name is available and the switch can succeed.?The branch is created and becomes current.

Start points are explicit history choices

A switch-created branch can start from an explicit `<start-point>`. For example, `git switch -c fixup HEAD~2` creates `fixup` at the resolved commit and then switches to it. This reuses Git’s revision-selection machinery; it does not create a new commit merely because a branch is created.

git switch -c fixup HEAD~2
git rev-parse --verify fixup^{commit}
git rev-parse --verify HEAD^{commit}

HEAD points to a later commit and HEAD~2 resolves to an earlier commit.?fixup names the earlier commit and is current.

Switch back and use the previous-branch shorthand

`git switch -` is shorthand for `git switch @{-1}`. The `@{-N}` form refers to the Nth previous branch or commit switched to by switch/checkout operations. This is a switching-history convenience, not a branch-management operation and not a reflog lesson.

git switch main
git switch topic
git switch -
git branch --show-current

main was followed by a switch to topic.?`git switch -` returns to the previous switch target, main.

Discard changes only when discarding them is intentional

`git switch --discard-changes <branch>` (also `--force`) tells Git to proceed even when the index or working tree differs from HEAD, restoring both to match the switching target. This is destructive to those local changes. It is therefore a deliberate state replacement, not a routine way to make switching “work.”

git switch --discard-changes topic
git status --short
git branch --show-current

Local changes would otherwise prevent the switch.?The target branch becomes current and the local changes are discarded.

Merge local changes during a switch only when that is the intended operation

`git switch --merge <branch>` uses a three-way merge when local modifications overlap differences between the current and target branches. If the reapplication produces conflicts, the index can contain unmerged paths that must be resolved. This is materially different from `--discard-changes`, which throws local changes away.

git switch --merge topic
git status --short
git diff

Local modifications exist and the learner wants to attempt to preserve them during the switch.?The switch may complete with preserved changes or leave conflicts to resolve.

Keep branch switching separate from detached HEAD

This lesson stops at making a named branch current. `git switch --detach <start-point>` deliberately removes the current branch association for inspection or experiments; that is the subject of the detached-HEAD lesson. Likewise, the precise role of HEAD as the symbolic reference to the current branch gets its own lesson so the learner can distinguish the branch name, HEAD, and working-tree state.

The learner understands named-branch switching.?The detached-HEAD lesson can introduce the different HEAD state without mixing concepts.

Practice what you learned

Use the dedicated Git code-completion exercise for this lesson.

Official-source boundary

This lesson uses only official Git documentation. The primary source is `git-switch`; supporting concepts use the official Git user manual and branch documentation. The current official git-switch manual is documented as unchanged in Git 2.56.0 after its 2.55.0 update. The local verifier is Git 2.47.3, so tests report observed behavior rather than silently claiming every version behaves identically.