Why are you using 'git pull' ?

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

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'

Comments

[Jesse Phillips]

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.

Cheatsheet for Git Rebase

Jesse Phillips ・ Apr 17 ・ 1 min read

#git #cheatsteet

[Nick Groos]

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.

[Jesse Phillips]

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.

Delete Your Master

Jesse Phillips ・ Apr 8 '19 ・ 1 min read

#git

[Ian Pride]

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

[Jesse Phillips]

Yeah that is useless for me as I

git fetch origin
git rebase origin/master

[Ian Pride]

Whatever works for you.

[Jesse Phillips]

git pull --rebase origin master

Would actually do what I do. So many options.

[Omri Gabay]

Because I git pull --rebase #yuh

[Nick Groos]

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

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