DEV Community

loading...

Why are you using 'git pull' ?

Nick Groos
I work on the full stack, whatever that means.
・1 min read

I have noticed that for whatever reason, new developers love to use git pull for merging code. To get latest from another branch, they will do something like this:

  1. Switch to the other branch
  2. git pull the latest code for that branch
  3. Switch back to the working branch
  4. Merge the freshly pulled code into the working branch

So, git pull can get the job done. And developers will go months or years unaware of the much more nimble git fetch.


The problem is that the steps above require us to switch branches, a slow git operation, two times. We can achieve the same outcome without switching branches by using git fetch:

git fetch origin develop
git merge origin/develop
Enter fullscreen mode Exit fullscreen mode

And we have the latest from /develop into our current working branch.

The seemingly small efficiency gained from a workflow that uses git fetch instead of git pull will result in hours of saved time over the course of a project.


For more context I recommend this discussion about 'git fetch' vs 'git-pull'

Discussion (10)

Collapse
jessekphillips profile image
Jesse Phillips • Edited

I don't, and I don't recommend it. However git pull seems to match other version control systems more closely.

This causes a familiarity where your objective is to bring remote changes into your working tree. But git has local branches, so you first need to update your local branch and then merge that into your other branch.

As you point out, this line of thinking is actually less efficient than updating your local database followed by a merge.

But that brings me to the other confusion, when do you use a space vs a slash. Clearly you use a space when naming a remote, but that isn't clear.

$ git merge origin develop

I want to merge the develop branch on origin. This seems logical, but the command does not operate on a remote, if I switch the command to pull it works as desired.

Introducing the idea that the entire remote repository is locally available is yet another topic to cover.

There are really only two operations that you can do with the remote repository, push your local database and pull their remote database. All other operations occur against the local database.

But the pull command creates confusion as I should have said fetch instead oy pull even though without all the git lingo you'd expect the same thing.

Don't even get me started on why github has you create "pull requests" when you are wanting them to merge in your changes.

Collapse
groos profile image
Nick Groos Author

Nice overview. Yes, the 'git pull' workflow is something I see very often, without a good reason to invest the extra time for the pull.

Collapse
jessekphillips profile image
Jesse Phillips • Edited

Your workflow example also isn't the most optimal one could

git pull origin <branch>

I understand one wouldn't do this as it does not update you local copy of the branch. My view on that is of course different.

Thread Thread
thefluxapex profile image
Ian Pride

That's why I alias git pull origin master to gpom.

Thread Thread
jessekphillips profile image
Jesse Phillips

Yeah that is useless for me as I

git fetch origin
git rebase origin/master

Thread Thread
thefluxapex profile image
Ian Pride

Whatever works for you.

Thread Thread
jessekphillips profile image
Jesse Phillips

git pull --rebase origin master

Would actually do what I do. So many options.

Collapse
omrisama profile image
Omri Gabay

Because I git pull --rebase #yuh

Collapse
groos profile image
Nick Groos Author

Yes, this is a good reason to use pull :D My post was inspired by those that use pull without knowing why!

Collapse
mw44118 profile image
W. Matthew Wilson

I like to use git fetch when I want to study somebody else's contributions locally in a new branch. If I like it, I merge it in. Or maybe I only cherry-pick a few commits.
But git pull is great! Nothing wrong with using it.

Forem Open with the Forem app