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.

Updated
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#

git fetch
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:

git log --oneline main..origin/main
git diff main origin/main -- README.md

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#

git pull [remote] [branch]
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:

git config --global pull.rebase true

Example: an ordinary update#

git pull
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#

git pull --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:

git merge --abort

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:

git reset --hard ORIG_HEAD

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

  1. Tidy the working directoryCommit or stash your edits: git pull does not like unfinished work.
  2. Download and lookgit fetch, then git log --oneline main..origin/main — exactly what will arrive.
  3. Choose the methodLinear history — --rebase; keep the join point — an ordinary merge.
  4. Resolve conflictsFix the files, git add, then --continue on the matching command.
  5. 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.

Start the plan

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

Was this helpful?

More articles

Programming and IT git merge Merging brings work from one branch into another. git merge takes the branch you name and joins its history with the current one — sometimes by just moving a pointer, sometimes by creating a separate commit, and sometimes by stopping and asking for help. Programming and IT git rebase git rebase moves the commits of your branch as if you had started work not from an old state but from the current one. History becomes linear, but the commits are created anew — with new hashes. That leads to the main rule: you can only rebase what nobody else is using. Programming and IT git checkout Historically `git checkout` does several unrelated things at once: it moves your working copy to another branch, creates a branch and pulls a single file out of a commit. Because it was so overloaded, Git 2.23 added two separate commands — `switch` and `restore`. Here are both sides: the old way and its modern replacement. Programming and IT Git branches A Git branch is a movable pointer to a commit, not a copy of your files. That is why creating one costs nothing, and the git branch command is what you use to list, create, rename and delete branches. Programming and IT How to undo a commit The question "how do I undo a commit" actually hides four different ones: fix the last commit, take it back and redo it, erase several, or cancel an old commit in the middle of history. The answer depends above all on one thing — whether anyone besides you has seen that commit. Programming and IT git commit A commit is a saved state of your project with an author, a timestamp and a message. git commit takes what you selected beforehand with git add and writes it into history as one indivisible piece.

More solutions