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:
- Switch to the other branch
-
git pullthe latest code for that branch - Switch back to the working branch
- 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'
Top comments (10)
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
pullit 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
fetchinstead 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
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.
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
That's why I alias
git pull origin mastertogpom.Yeah that is useless for me as I
git fetch origingit rebase origin/masterWhatever works for you.
git pull --rebase origin masterWould actually do what I do. So many options.
Because I
git pull --rebase#yuhYes, this is a good reason to use pull :D My post was inspired by those that use pull without knowing why!
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.