Do I have to 'pull' to merge the latest into my local branch in git?

Question

Forgive my shallow understanding of git , but I see this pattern often and I'm wondering if it's necessary. I see people doing this (working in my-dev-branch which was branched from master ):

git checkout master
git pull
git checkout my-dev-branch
git merge master

Could you achieve the same thing with:

git fetch
git merge master

Or even:

git merge origin/master

Answer 1

git pull is by definition a combined git fetch followed by a git merge (barring exceptions when arguments or configuration override the default). The documentation says so explicitly:

Incorporates changes from a remote repository into the current branch. In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD .

Some people advise against using git pull at all. The reasons range from depriving you from a learning opportunity (that will lead to better understanding and usage of git) to the fact it automatically creates a relatively nasty merge commit. The bottom line being that it has the ability to do enough behind the scenes that it's hard to know exactly what the end result will be. Perhaps most importantly, it denies you the opportunity to examine the commits and choose how best to integrate them with your local changes.

git merge origin/master cannot, by itself, replace git pull . The reason for this is simple: it won't perform a fetch. origin/master is not actually referencing a branch in a remote repository. It's a local ref on locally stored commits with metadata indicating it should mirror a branch in a remote repository, so changes to the remote repository must be fetched before they're available in origin/master .

However, if the master branch is configured so that its tracking branch is origin/master , then git merge and git merge origin/master are equivalent:

If no commit is given from the command line, merge the remote-tracking branches that the current branch is configured to use as its upstream.

( git merge Documentation )

So this would be equivalent if preceded by a fetch. It is less convenient and slightly more error prone, though.

Answer 2

There are two concepts at work, and two types of merges which are happening. The first type of merge is the one which occurs when you do the first two commands:

git checkout master
git pull

Assuming you have your pull strategy set to merge (rather than rebase), doing git pull on the master branch will first fetch any changes from the remote master and then merge them into your local copy of this branch.

The second merge which happens is when you do the following two commands:

git checkout my-dev-branch
git merge master

This switches to the my-dev-branch and then merges the local master branch into it.

Now here's where things get interesting. Suppose you do this:

git checkout master
git fetch
git merge origin/master

It turns out this is the same thing as doing what you had originally:

git checkout master
git pull

Running git fetch will update your special local branches which track the remote. In the case of master I expect this branch to be called origin/master . So by merging this remote tracking branch into your local master you are effectively doing the same thing as merging the remote.