Creating and Switching Branches

Creating a branch gives a Commit another name. Switching branches changes which branch HEAD selects and may update tracked files in the Working Tree. These are separate operations, and understanding their effects matters most when local changes are present.

Create, list, and select

While HEAD is on master at Commit C3:

git branch feature
git branch

The first command creates feature at C3 without switching to it. git branch lists local branches and marks the current one with *:

  feature
* master

Use git switch feature to select the existing branch. Then HEAD symbolically points to refs/heads/feature, and the * moves to feature. To create and select a branch in one operation, use git switch -c review. A branch can also start at a specified existing Commit with git switch -c review <commit-id>; identify the intended starting point before doing so.

The older git checkout <branch> can switch branches too, but checkout has other responsibilities. Prefer switch when the task is selecting a branch; both commands protect local changes from being overwritten.

What switching changes

If feature has a new Commit containing branch-switch-lab.txt and master is still at its parent, switching to master removes that tracked file from the Working Tree. The file is still stored in the Commit on feature and reappears when switching back.

An untracked file such as object-lab.txt can remain in the Working Tree while moving between branches. A pending edit is not permanently assigned to the branch where it began. If it travels to another branch and is committed there, that branch receives the Commit.

Different branch tips do not decide switch safety

Git checks whether it can set up the target branch’s Index and tracked Working Tree files while preserving local edits.

Suppose the branches differ because feature added branch-switch-lab.txt, but both branches record the same app.txt. An unstaged edit to app.txt can travel with you when switching because Git need not replace that file. The branches can point to different Commits and the switch can still succeed.

Different committed versions of a file are also normal: with no conflicting local edit, Git can update the Working Tree to the target version.

When Git refuses

If you modify branch-switch-lab.txt locally on feature and then switch to master, Git would need to remove that tracked file. The switch is rejected to protect the edit:

error: Your local changes to the following files would be overwritten by checkout:
        branch-switch-lab.txt
Please commit your changes or stash them before you switch branches.
Aborting

The attempted switch leaves the current branch and local changes intact. Git also refuses when an untracked local file has the same path as a tracked file that the target branch needs to place in the Working Tree.

Read the error and inspect git status before deciding what to do. A coherent Commit can preserve completed work. Stash and worktrees are later topics with different uses. Do not create a misleading Commit just to make a switch succeed.

A safe routine

1. Run git status before switching.
2. Identify which tracked and untracked files have local changes.
3. Predict which files the target branch needs to update.
4. Switch if Git can preserve the changes; otherwise save or relocate the work deliberately.
5. Run git status again and check the current branch before making a Commit.

Common mistakes

• Expecting git branch feature to select feature.
• Assuming uncommitted edits belong to a branch forever.
• Assuming different branch tips always make a switch unsafe.
• Assuming a switch can overwrite a modified or colliding untracked file.
• Committing a carried edit on the wrong branch without checking HEAD.

Summary

git branch creates a branch; git switch selects one; git switch -c does both. Pending changes may travel between branches when Git can preserve them. Git refuses a switch that would overwrite local work, including an untracked path collision. Inspect status and the current branch before committing.

Knowledge check

After git branch feature on master, where is HEAD?

Still on master. The new feature reference points to the current Commit until it moves independently.

An unstaged edit follows you from master to feature. Where does a new Commit record it?

On feature, if you stage and commit it while feature is current. Git does not remember which branch was current when the edit began.

Why can Git reject switching away from a locally modified tracked file?

If setting up the target branch requires replacing or removing that file, the switch would discard the local edit. Git aborts and keeps the current state.