Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
After git fetch, how to fast forward my branch?
I did git fetch
to quickly get latest commits. I did this instead of git pull
so I could deal with merge conflicts offline. But my repository is still stuck on the old commit, and now git pull
fails because I can no longer connect to the internet. How do I "activate" the changes that I fetched?
2 answers
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.
-
This configuration can be added for merges as well as for pulls, but I find that the
pull.ff
config set toonly
gives me the confidence to pull whenever I want. If a fast forward is unavailable, Git just does a fetch without merging. I don't bother settingmerge.ff
toonly
, since I only evergit merge
commits I already have locally and I'm pretty cognizant of when it'll merge or fast forward. ↩︎
tl;dr
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
runsgit fetch
with the given parameters and then depending on configuration options or command line flags, will call eithergit rebase
orgit 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 its name in the command line.
0 comment threads