Safeguard
DevSecOps

Git Checkout Dev: Switching to a Development Branch Safely

git checkout dev switches your working tree to the dev branch, but the safe workflow around it matters more than the command. Here is how to do it without losing work or leaking secrets.

Marcus Chen
DevSecOps Engineer
5 min read

Running git checkout dev switches your working directory to the branch named dev, updating your files to match that branch's latest commit. It is one of the most-typed Git commands, but the failure modes around it — losing uncommitted work, checking out a stale copy, or accidentally committing secrets on the wrong branch — cause more lost time than the command itself ever saves. This walks the mechanics and the safe habits.

The basic command

If a local branch called dev already exists:

git checkout dev

Git updates the files in your working tree to match dev and moves HEAD to point at it. On Git 2.23 and later there is a clearer, purpose-built alternative that many teams prefer:

git switch dev

git switch only changes branches, while git checkout is overloaded to also restore files, which is a common source of foot-guns. Both leave you on dev; switch just makes intent obvious.

Checking out a remote dev branch for the first time

If dev exists on the remote but you have never checked it out locally, fetch first, then create a tracking branch:

git fetch origin
git checkout dev          # modern Git auto-creates a tracking branch

Modern Git detects the matching origin/dev and sets up tracking automatically. If you are on an older client or want to be explicit:

git checkout -b dev origin/dev

This creates a local dev that tracks origin/dev, so later git pull and git push know where to go.

Handling uncommitted changes before you switch

This is where people lose work. If you have modified files and try to switch, Git either carries the changes over (if they do not conflict) or refuses with an error about overwriting local changes. Do not force past it blindly. You have three clean options:

# Option 1: commit the work in progress
git add -A && git commit -m "WIP: save before switching"

# Option 2: stash it and reapply later
git stash push -m "before switching to dev"
git checkout dev
git stash pop        # when you return to the original branch

# Option 3: discard if you truly do not want it (destructive)
git restore .

Reach for stash when the work is not ready to commit but you do not want to lose it. Reserve the destructive option for changes you are certain you want gone.

Keeping dev current after you check it out

Landing on dev does not mean it is up to date. Pull the latest before you start work:

git checkout dev
git pull --ff-only origin dev

The --ff-only flag refuses to create a surprise merge commit; if your local dev has diverged, it stops and tells you, which is exactly what you want to know before layering new work on top.

The security habits that ride along

Branch switching is also a moment where secrets and bad artifacts slip in. A few practices that belong in any DevSecOps workflow:

  • Confirm which branch you are on before committing: git branch --show-current. Committing an API key on dev and pushing it is a common leak.
  • Keep a .gitignore that excludes .env, credentials, and build output so a stray git add -A does not sweep them up.
  • Run a pre-commit hook that scans staged changes for secrets before they ever reach the remote.

A quick sanity check before committing:

git branch --show-current
git status
git diff --staged

Those three commands take two seconds and prevent the two most common mistakes: committing to the wrong branch and committing something you did not mean to.

When checkout is not what you want

If your goal is to work on a new feature, do not develop directly on a shared dev. Branch from it:

git checkout dev
git pull --ff-only origin dev
git checkout -b feature/new-thing

This keeps dev as an integration branch and isolates your work until it is reviewed and merged. Shared branches that everyone commits to directly are where parallel work collides and where unreviewed changes reach main.

FAQ

What does git checkout dev do?

It switches your current branch to dev, updating the files in your working directory to match that branch's latest commit and pointing HEAD at it.

What is the difference between git checkout and git switch?

git switch only changes branches and is the modern, intent-clear command introduced in Git 2.23. git checkout does the same thing but is also overloaded to restore files, which makes it easier to misuse.

How do I check out a dev branch that only exists on the remote?

Run git fetch origin then git checkout dev. Modern Git creates a local tracking branch automatically. On older clients use git checkout -b dev origin/dev.

What happens to my uncommitted changes when I switch branches?

Git carries non-conflicting changes over, or refuses to switch if they would be overwritten. Commit or git stash your work first to avoid losing it.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.