tl;dr ^[1]

git merge origin/branch_name

_{Or rebase instead of merge}

Long answer

When your local repository has one or more remotes configured, there are special branches that the documentation calls "remote-tracking 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 there is some remote repository, which has just the branch main. After cloning it (git clone remote-url), the situation will be like this:

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:

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.

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

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 in the remote repository is pointing to commit B, whose parent is commit A". That's why origin/main in the local repository 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:

"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.

posted 5 months ago

CC BY-SA 4.0

21h ago

hkotsubo‭

5110 reputation 20 69 575 228

The answer by hkotsubo is correct. But just in case you're being very specific about fast-forwarding, it's worth stressing that you can use --ff-only as an option on the merge to abort if it requires a merge commit.

git merge --ff-only origin/branch_name

Where is this useful? I have my git pull set to fail if the merge would create a merge commit. Typically, I'd rather rebase my new commits than make a merge commit unnecessarily.

[pull]
    ff = only

But that only happens for pulls.^[1] If I explicitly ask for a merge after fetching, Git's going to give me a merge, even if it makes a merge commit… unless I --ff-only it not to.

posted 5 months ago

CC BY-SA 4.0

5mo ago

Michael‭

806 reputation 2 19 84 70