Git Pull: How It Works With Detailed Examples

If you’re working alone on a project, you can use Git locally just fine. Most of the time, however, you’ll be collaborating with other people. To sync with remote repositories, you’ll need to master Git network operations, including git pull.

This post will explain git pull in detail. You’ll learn what this command does and how to use it, in addition to learning useful fundamentals about network operations in Git. As is usual for these tutorials, we assume you have Git installed and are at least familiar with working with the command line. 

What is git pull? In a nutshell, it’s the command you use to update your repository with new changes.

To better understand git pull, you need to understand how network operations work in Git.

Unlike in other VCSs, commits in Git aren’t deltas. Instead of storing the patch—that is, the actual changes introduced—they store a whole snapshot of the project in a specific instant.

Git commits are identified by a unique-ish identifier, which is calculated based on their data, including the name and email of the author, time stamp, commit message and the commit’s parents.

Git is a decentralized VCS, which means there’s no central server. Instead, in Git you can have any number of remote repositories, or simply remotes.

In practice, however, most projects will have a “main” remote, which acts as the de facto central server.

You collaborate in Git by exchanging information with your remotes. As we’ve mentioned, you can have any number of remotes. And, despite being common for projects to have a main remote playing the role of a “central server,” you can also have other remotes configured. 

For instance, you can add your coworker’s repository as a remote so both of you can collaborate. As soon as you get your remotes configured, you can send and get commits from the branches in your remotes.

How does that work in practice? For starters, you have your local branches in which you do your work. Your remote repositories also have their branches, which are appropriately called “remote branches.” The last part of this tripod is what makes the whole thing possible: remote-tracking branches.

Remote-tracking branches are references that live in your local repositories. You can think of remote-tracking branches as “read-only” branches that mirror the state of the actual remote branches.

Time to understand git pull more in-depth.

Git pull, in a nutshell, is a two-part process. First, your remote-tracking branch is synced with the “true” branch in the remote repository.

Then, your local branch is compared to the remote-tracking branch and receives the new commits so it can catch up to the current state of the remote branch.

It’s common for beginners to mix up git pull and git fetch. Despite being related, they’re two different operations. Let’s see how they’re similar and how they’re not.

Git fetch, to put it simply, is the process of updating the remote-tracking branches. When you run this command, Git fetches the new commits from the remote. After fetching, you can merge the received commits into a local branch, using git merge.

And what about git pull? You can think of this command as a shortcut: it does all of the above in a single step. In other words: git pull = git fetch + git merge.

Another common question beginners have when it comes to git pull is how it compares with git push.

Well, they’re similar in that they’re both very common commands in Git and both are related to network operations. However, when it comes to results, they couldn’t be more different—they’re opposite operations.

Pulling means getting commits from the remote. Pushing means sending things to the remote.

Finally, it’s time for you to roll up your sleeves and start doing some work so you can learn how to use git pull in practice. 

Let’s start by creating a local repository and adding some commits:

mkdir demo
cd demo
git init
echo hi > file && git add . && git commit -m "Add first file"
echo hi > file2 && git add . && git commit -m "Add second file"
echo hi > file3 && git add . && git commit -m "Add third file"

You now have a repo with three files and three commits in it. Nice.

For the next step, you’ll need a GitHub account. So, if you don’t have one, now is the time to create it. Then, sign in to GitHub and go to the new repository page. Create a new repository, choosing any name you like.

Now you’re going to add this repo on GitHub as a remote to your local repository so you can push your commits. Run the following commands:

git remote add origin <THE URL OF YOUR REPO ON GITHUB>
git branch -M main
git push -u origin main

Of course, make sure to replace the repo’s URL with the correct URL for your repository. After running the commands above, you can go back to your browser, go to the repo’s front page, and you should see your three commits:

Now let’s simulate another user collaborating to the same remote. Using the command line, go to a different folder and clone the repository, using the GitHub URL:

git clone <THE URL OF YOUR REPO ON GITHUB>

Go back to the original folder, add some new commits, and push them:

echo hi > file4 && git add . && git commit -m "Add fourth file"
echo hi > file5 && git add . && git commit -m "Add fifth file"
git push

Now you’re finally ready to use git pull! Go to the folder in which you cloned the repository. First, run the following command:

git fetch origin main

With the command above, you fetch changes from the branch main in the remote called origin. Nice. But if you run git log, you’ll see that your local branch main still has the same three commits as before. What’s happening?

Well, as explained, git fetch updates your remote-tracking branches but not your local ones. Run git status and you’ll see a message saying that your local branch is two commits behind the remote one:

Git tells us to use git pull to update the local branch. But let’s not do that right now. Instead, you can simply merge the remote-tracking branch into your local one:

git merge origin/main

Congratulations! You have just pulled changes from a remote repository, even without using the git pull command itself. But don’t worry: The next step is actually using the command.

Now you’ll do the opposite of what you’ve done before. While in the cloned repository, add one commit—or more, if you are so inclined—and push it to the remote:

echo more lines >> file && git add . && git commit -m "Change first file"
git push

Now go back to the original folder and follow the instructions:

• First, run git status. Git will tell you the repository is clean, nothing to worry about.

• Then run git fetch.

• Next, run git status again. Git will say your branch is one commit behind.

• Finally, run git pull to update your local branch.

Before wrapping up, let’s answer another common question: What’s the relationship between the pull operation in Git and the concept of a pull request?

Well, git pull is a native command from Git. A pull request, on the other hand, is a feature from GitHub. A pull request is the event in GitHub in which a contributor to a project sends a potential contribution, asking for it to be merged to the project’s code.

Why is it called a pull request, then, instead of a merge request?

To be fair, the name of the operation is indeed a little bit confusing. The explanation is simple, though: When you send a pull request, you’re asking for the project’s maintainer to pull commits from your branch and merge them into their repository.

Conclusion

Git can be used 100% offline. However, if you want to collaborate with other people, you’ll need to understand the networking aspects of the tool. So, mastering commands such as git pull and git push is crucial if you want to collaborate while using Git.

It doesn’t stop there, though. You should also learn more about branches in general—for example, how to create them, how to switch from one branch to another, how to check out a remote branch and more.

You also might want to learn about references in Git and how they work, including learning about HEAD and understanding what a detached HEAD is and how to fix it.

This post was written by Carlos Schults. Carlos is a consultant and software engineer with experience in desktop, web, and mobile development. Though his primary language is C#, he has experience with a number of languages and platforms. His main interests include automated testing, version control and code quality.