If you work on a team using Git, you've almost certainly run into this situation: a teammate has pushed a new branch, and you need to pull it down and start working on it locally. Once you've done it a few times it feels routine, but without a clear understanding of how fetch, checkout, and tracking relate to each other, it's easy to end up working on the wrong branch or running into errors when you push or pull. This article breaks down the whole workflow in a systematic way.
What git fetch Does and How to Use It
The first step to getting a branch created by someone else is git fetch. The key thing to understand here is that fetch only downloads information from the remote repository — it does not touch your working directory at all.
# Fetch all latest information from the remote
git fetch origin
# Fetch a specific branch only
git fetch origin feature/user-authAfter running fetch, a remote-tracking branch like origin/feature/user-auth will be created or updated in your local repo. At this point you've only learned about the remote's state — you don't yet have a local working branch.
When I was first learning Git, I couldn't really tell the difference between git fetch and git pull, so I just used pull for everything. But pull actually runs fetch and merge (or rebase) together in one step. To avoid unintended merges, it's worth building the habit of fetching first, reviewing what changed, and then deciding what to do next.
To see what remote branches are available, these commands are useful:
# List remote branches
git branch -r
# List both local and remote branches
git branch -aA common source of confusion is fetching and then not seeing the branch you expect. In that case, try git fetch --prune. Old references to branches that have been deleted on the remote can clutter your local branch list and make it hard to find what you're looking for.
Creating and Switching to a Local Branch with checkout
Once you've fetched the remote branch information, the next step is to create a local branch and start working. You do this with git checkout or git switch.
# Create a local branch with the same name as the remote and switch to it
git checkout feature/user-authThere's a handy automatic behavior built into this command. If no local branch named feature/user-auth exists, but exactly one remote has origin/feature/user-auth, Git will automatically create a local branch based on that remote-tracking branch. This behavior is called "DWIM mode" (Do What I Mean).
However, if you have multiple remotes configured, this auto-detection may not work correctly. In that case, specify the remote-tracking branch explicitly:
# Explicitly specify the remote-tracking branch when creating
git checkout -b feature/user-auth origin/feature/user-authYou can also use the git switch command, introduced in Git 2.23. Because checkout serves two distinct purposes — switching branches and restoring files — switch was introduced as a dedicated command just for branch operations.
# The equivalent operation using switch
git switch feature/user-auth
# Explicitly creating the branch
git switch -c feature/user-auth origin/feature/user-authWhether you use checkout or switch comes down to team preference, but newer projects seem to be adopting switch more often. Neither is strictly better than the other, so the important thing is to pick one and stay consistent as a team.
Understanding Tracking: How to Set It Up and Verify It
The link between a local branch and its corresponding remote branch is called upstream tracking. When you create a local branch via checkout or switch as described above, tracking is configured automatically. But if you create a branch manually or the tracking association gets broken, you'll need to set it explicitly.
# Set the upstream for an existing local branch
git branch --set-upstream-to=origin/feature/user-auth feature/user-auth
# Shorthand
git branch -u origin/feature/user-authTo verify that tracking is configured correctly, run:
# Show tracking information for each branch
git branch -vvThe output will look something like this:
main a1b2c3d [origin/main] Latest commit message
* feature/user-auth e4f5g6h [origin/feature/user-auth] Implement authenticationIf you see [origin/feature/user-auth] next to the branch name, tracking is set up. With tracking in place, you can run git pull and git push without any extra arguments, which makes your day-to-day workflow noticeably smoother.
Tracking was something I overlooked early on, but once I understood it, I no longer had to type the remote branch name every time I pushed — a small but real improvement to my workflow.
A Practical End-to-End Workflow
Putting everything together, here's a practical workflow for fetching a remote branch and starting local work:
# 1. Fetch the latest remote info and clean up stale references
git fetch --prune origin
# 2. Verify the target remote branch exists
git branch -r | grep feature/user-auth
# 3. Create a local branch and switch to it
git switch feature/user-auth
# 4. Confirm tracking is configured correctly
git branch -vv
# 5. Do your work, commit, and push
git add .
git commit -m "Fix authentication logic"
git pushOnce this flow becomes second nature, you'll rarely feel lost when working with remote branches in a team setting.
One thing to keep in mind: if you're resuming work on a branch that hasn't been updated in a while, always run git pull first to pick up the latest changes from the remote. If conflicts arise, fetching first to assess the situation before resolving them is the safer approach.
Conclusion: Mastering the Basics Raises the Quality of Team Development
Fetch, checkout, and tracking are the fundamentals of Git branch management. Looking back, I realize I used them in a vague, intuitive way for a long time — and that vagueness was the root cause of many small frustrations.
To summarize each role clearly: fetch safely downloads remote state to your local machine; checkout and switch create and switch local branches; and tracking links local and remote branches so that push and pull just work without extra arguments.
Having a precise understanding of these basics — and making sure the whole team shares that understanding — is the foundation for a smooth, productive development workflow.
At aduce, we offer IT advisory services to help teams optimize their entire development process, including Git workflows, and build effective team development practices. If you're looking to improve your development workflow or level up your team's technical skills, feel free to reach out via aduce's contact page.