Post History

# tl;dr

~~~bash
git merge origin/branch_name
~~~

<sub>Or `rebase` instead of `merge`</sub>

# Long answer

When your local repository has one or more remotes configured, there are special branches that the documentation calls ["remote-tracking branches"](https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches).

Basically, those branches serve "*as bookmarks, to remind you where the branches in your remote repositories were the last time you connected to them*". Their names follow the format "remote_name/branch_name".

Example: let's say you clone some repository, which has just the branch `main`. Your local repository will be like this:

~~~none
Remote
All previous commits... <- commit A (main)

Local (after git clone)
All previous commits... <- commit A (main, origin/main)
~~~

Your local repository has the local branch `main`, and the remote-tracking branch `origin/main` (both pointing to the same commit A). The latter indicates the state of the branch `main` in the remote repository when you cloned it.

Now let's say someone else pushed to the remote repository, while you also changed your local one:

~~~none
Remote (someone else pushed commit B)
All previous commits... <- commit A <- commit B (main)

Local (you added commit C)
All previous commits... <- commit A (origin/main) <- commit C (main)
~~~

Note that the changes you made locally affected only your local branch `main`. The remote-tracking branch `origin/main` still points to commit A, because that's the status it got the last time you synchronized with the remote (in this case, when you cloned it). Your local repository is still unaware of commit B.

> You can't move remote-tracking branches. They are moved by Git when you synchronize with the remote repository (when you clone, fetch or pull).

So let's get the new commits from the remote, by running `git fetch`. The result will be:

~~~none
Remote
All previous commits... <- commit A <- commit B (main)

Local (after git fetch)
All previous commits... <- commit A <- commit C (main)
                              ^
                              |
                          commit B (origin/main)
~~~

After fetching, your local repository is updated with the current status of the remote repository. In this case, the only change is: branch `main` now points to commit B, whose parent is commit A. That's why `origin/main` now points to commit B.

Therefore, in order to update your local branch `main`, you just need to merge it with `origin/main` (either by using `git merge` or `git rebase`, it depends on your preferences or specific project workflow, etc).

By the way, [the documentation says](https://git-scm.com/docs/git-pull) that "*`git pull` runs `git fetch` with the given parameters and then depending on configuration options or command line flags, will call either `git rebase` or `git merge` to reconcile diverging branches*". Which means that, when you fetched, you already did the first part of `git pull`, and a simple merge or rebase is enough to complete it.

But there's a corner case. Let's say you fetch, review and merge, but while you were reviewing, someone else pushed new commits. If you just merge instead of pulling, you won't get those new commits, as you're merging only the ones you've got when you fetched. But of course you could pull (or fetch+merge) again to get the remaining commits when your network is back.

---

PS: I'm assuming your remote's name is "origin" (which usually is, for most cases). But of course this explanation is valid for any remotes you might have configured, and you just need to change the name in the command line.