To git pull a remote branch, first make sure your local branch is tracking the remote one, then run git pull, which fetches the remote commits and merges them into your current branch in a single step. The confusion most people hit is not the pull itself but the checkout: getting a copy of a branch that exists on the remote but not yet on your machine. This guide covers both, plus the tracking setup that makes everything predictable, and it works the same on GitHub, GitLab, and Bitbucket.
Fetch first, understand what pull really does
git pull is not a single primitive. It is git fetch followed by an integration step (a merge by default, or a rebase if you ask for one). Fetch downloads the remote's commits and updates your remote-tracking references, such as origin/main, but touches nothing in your working directory. The merge or rebase then integrates those commits into your checked-out branch.
Understanding that split is what keeps you out of trouble. When you want to see what changed on the remote without altering your work, fetch:
git fetch origin
git log --oneline HEAD..origin/main # what you are about to pull in
When you are ready to integrate, pull:
git pull origin main
If you dislike surprise merge commits on shared branches, configure pull to rebase:
git config --global pull.rebase true
Checkout a remote branch for the first time
This is the "git checkout remote branch first time" case, and modern Git makes it easy. Say a colleague pushed a branch called feature/login and you have never had it locally. First update your view of the remote, then check it out by name:
git fetch origin
git checkout feature/login
Since Git 2.23-era versions, if a branch of that exact name exists on exactly one remote, git checkout feature/login (or the newer git switch feature/login) automatically creates a local branch that tracks origin/feature/login. You do not need anything fancier for the common case.
If the name is ambiguous or you want to be explicit, spell out the tracking relationship:
git checkout -b feature/login origin/feature/login
# equivalent, newer syntax:
git switch -c feature/login --track origin/feature/login
Either way you now have a local feature/login that knows its upstream, so a bare git pull from it will do the right thing.
If you fetched but Git says the branch does not exist, your remote-tracking refs may be stale. Prune deleted branches and refetch:
git fetch --prune origin
git branch -r # list all remote branches you can see
git branch -r is the quickest way to confirm the branch is actually visible to you before you try to check it out.
Why tracking branches matter
A tracking branch is a local branch linked to a specific remote branch. That link is what lets you type git pull and git push with no arguments and have Git know where to go. Check the relationships with:
git branch -vv
Each line shows the local branch, its upstream in brackets like [origin/main], and how far ahead or behind you are. If a branch shows no bracket, it has no upstream, and a bare git pull will complain. Fix it in one command:
git branch --set-upstream-to=origin/feature/login
This is the same on GitLab as anywhere else; a "gitlab checkout remote branch" is identical to GitHub because the remote protocol is the same. Only the hosting UI differs.
Handling pull conflicts and diverged history
Two situations cause a pull to stop.
If your local branch and the remote have both moved on, a merge produces a merge commit or, with rebase, replays your commits on top. Either can hit conflicts. Git pauses and marks the conflicting files. Resolve them, then continue:
# after editing the conflicted files
git add <resolved-files>
git rebase --continue # or: git commit, if you merged
If you have uncommitted local changes when you pull, Git will refuse rather than clobber them. Either commit them, or stash them and reapply after:
git stash
git pull origin main
git stash pop
One habit worth building: before pushing a branch that came out of a rebase or a conflicted merge, grep the diff for leftover conflict markers. A <<<<<<< or >>>>>>> accidentally committed will break a build and can quietly ship broken config. A quick check catches it:
git diff --check
git diff --check flags whitespace errors and conflict markers before they leave your machine.
A note on trusting what you pull
Pulling code is pulling someone else's changes into your build, and that is a supply-chain moment worth respecting. On shared repositories, protect important branches so history cannot be force-pushed out from under you, and consider requiring signed commits so you can verify who authored what. When a pull brings in changes to your dependency manifests, that is exactly when a new vulnerable package can slip in, which is why many teams run a software composition analysis check on every push rather than trusting that a green pull means safe code. The Git mechanics get the code onto your machine; the review and scanning decide whether it belongs in your release.
FAQ
What is the difference between git fetch and git pull?
git fetch downloads commits from the remote and updates your remote-tracking references without changing your working files. git pull runs a fetch and then immediately integrates those commits into your current branch by merging or rebasing. Fetch is safe to run anytime; pull changes your working branch.
How do I checkout a remote branch for the first time?
Run git fetch origin to update your view of the remote, then git checkout <branch-name>. If the branch exists on exactly one remote, Git automatically creates a local tracking branch. To be explicit, use git checkout -b <branch> origin/<branch>.
Why does git say the remote branch does not exist?
Usually your remote-tracking references are stale. Run git fetch --prune origin to refresh them and remove deleted branches, then git branch -r to confirm the branch is visible. If it still is not listed, it may not have been pushed to that remote.
Is checking out a remote branch different on GitLab?
No. GitLab, GitHub, and Bitbucket all use the same Git remote protocol, so git fetch and git checkout work identically. Only the web interface and access controls differ between the hosting platforms.