Programming and IT
git pull
git pull brings other people's commits from a remote repository and immediately merges them into your current branch. It is two operations in a row, and almost every problem with pull comes from the second one — how it joins the two histories.
In this article
Two operations under one name#
git pull is git fetch plus joining. First Git downloads new commits from the
remote repository and updates the tracking pointers such as origin/main. Then
it merges origin/main into the branch you are on — with a merge or a rebase,
depending on your settings.
The first half is always safe: what was downloaded sits separately and does not touch your files. The second half changes the working directory and can run into a conflict. The practical conclusion: when you are unsure of the project's state, do these steps separately.
fetch when you want to look first#
From https://github.com/example/notes
4f1c2ab..8b2d5e9 main -> origin/main
Your local main has not moved, but now you have something to compare against:
The first command lists the commits you do not have, the second shows the
line-by-line difference in a specific file. Look first, merge afterwards:
git merge origin/main or simply git pull.
Syntax and ways of joining#
| Option | How it joins |
|---|---|
--rebase |
replays your commits on top of the downloaded ones; history stays linear |
--no-rebase |
an ordinary merge; if histories diverged, a merge commit appears |
--ff-only |
merges only by fast-forward; on divergence it simply refuses |
--autostash |
sets aside uncommitted edits and puts them back afterwards |
To avoid choosing every time, set it once per machine:
Example: an ordinary update#
Updating 4f1c2ab..8b2d5e9
Fast-forward
README.md | 4 ++++
1 file changed, 4 insertions(+)
Fast-forward means the best case: you had no commits of your own, and the branch
pointer just moved forward. If you had committed something, Git would join the
two histories and print Merge made by the 'ort' strategy — how such a merge
works is explained in the article on git merge.
Example: pull with rebase#
Successfully rebased and updated refs/heads/main.
Your commits are recreated on top of the others — with new hashes but the same content. History stays linear, with no "herringbone" of merge commits. This is the most common answer when the server rejects a push — see git push. One important limit: only rebase your own unpushed commits, otherwise your teammates are left with an old copy of the same changes. The mechanism is covered in git rebase.
When pull stops#
hint: You have divergent branches and need to specify how to reconcile them.
fatal: Need to specify how to reconcile divergent branches.
Git sees that the histories diverged and does not want to choose for you. The
answer is one of the settings pull.rebase true, pull.rebase false or
pull.ff only.
error: Your local changes to the following files would be overwritten by merge:
README.md
Please commit your changes or stash them before you merge.
Aborting
Your uncommitted edits collided with incoming ones. Commit them, or set them aside
with git stash, update and bring them back with git stash pop, or run
git pull --autostash once.
The third case is a conflict: you and a teammate changed the same lines of a file. Git leaves conflict markers in the file and waits for you to decide — see how to resolve a merge conflict.
How to roll back#
The update did not finish — abort the half that got stuck:
or git rebase --abort if you pulled with --rebase. Both put the branch and the
files back exactly as they were before the command.
The pull finished, but you do not like the result:
ORIG_HEAD is where Git recorded the branch before the last big operation. The
command erases uncommitted edits, so make sure you have nothing to lose. If even
that does not help, the earlier position of the branch can always be found in
git reflog. The other everyday commands are in the
cheat sheet.
Step-by-step plan
- Tidy the working directoryCommit or stash your edits: git pull does not like unfinished work.
- Download and lookgit fetch, then git log --oneline main..origin/main — exactly what will arrive.
- Choose the methodLinear history — --rebase; keep the join point — an ordinary merge.
- Resolve conflictsFix the files, git add, then --continue on the matching command.
- Check the resultgit status is clean, git log --oneline --graph -10 shows the picture you expect.
Start learning this in your own space
The plan goes into your repository: tick off stages, keep notes — the change history shows how far you have come.
Check yourself
1.How does git fetch differ from git pull?
2.Pull stopped with “Your local changes would be overwritten by merge”. What do you do?
3.Which option updates the branch without a merge commit by replaying your commits on top of the others?
Sources
-
Pro Git bookThe chapters on remote repositories and rebasingfree
-
git pull referenceOptions and how it relates to fetch and mergefree
-
git fetch referenceWhat exactly a fetch updatesfree
Was this helpful?