The branch was wrong, the clock was ticking, and the deploy window was closing. You type one command:
git checkout team-lead
In Git, branches are more than names. They are work surfaces, context switches, and isolated lines of development. When a branch like team-lead exists, it signals a purpose—often tied to a specific role, feature, or coordination point in the workflow. Checking it out moves your HEAD pointer there. Your local files change instantly to match that branch’s state.
Use git branch to see if team-lead exists locally. If it does not, run:
git fetch origin
git checkout team-lead
This pulls the remote branch and sets up tracking so future git pull commands stay in sync. For safety, use git status before switching to ensure you have no uncommitted changes that could cause conflicts.
When collaborating, git checkout team-lead can mark a handoff. The branch might contain approved changes from the lead, in-progress review code, or a stable checkpoint. Keeping it up to date with git pull origin team-lead ensures alignment with the latest decisions. Avoid force pushes unless you control the branch fully—shared branches are coordination tools, and history rewrites can break trust.
If you’re done on the branch, you can switch away:
git checkout main
git branch -d team-lead
Use -D only if you are certain you no longer need the work.
The git checkout command is evolving. In newer Git versions, git switch team-lead is the simpler way to change branches. But git checkout remains universal, especially in automation scripts and older environments.
Control your workflow. Know where your HEAD is. Switch with intent.
See it live with real branching, deployment previews, and instant environments—get started in minutes at hoop.dev.