58

I've read from various sources that it's usually a better idea to fetch then merge rather than simply pull as it allows for finer control. That said, I've yet to find actually how to do it. Case in point:

There was a small change made to some of the code in one of my GitHub repository's master branch. I was able to fetch it, but I don't know how to actually merge the differences in with my local master branch. git branch lists all of the local branches I have, but nothing indicating anything to merge to.

So, is it just something like git merge master or git merge origin/master? What am I missing?

mfaani
  • 33,269
  • 19
  • 164
  • 293
Major Productions
  • 5,914
  • 13
  • 70
  • 149
  • 2
    If you're working on the master branch anyway, there's no point in not doing `git pull`, since `git pull` is just an alias for `git fetch && git merge origin/master` – Brendan Jan 25 '13 at 00:24
  • 1
    Since you're just learning git, have you considered working on a branch? They're really easy & disposable, too. I've found that it's just easiest to just always work on a local topical branch, then , rebase to master, and finally push. – Mike Monkiewicz Jan 25 '13 at 04:18
  • I do that, but if I want to keep my own master up-to-date as I'm working on my own feature in another branch, I need to fetch/pull from origin/master. I was just wondering about the actual command(s) to do it. – Major Productions Jan 25 '13 at 13:10

4 Answers4

63

git merge origin/master should work. Since master is usually a tracking branch, you could also do git pull from that branch and it will do a fetch & merge for you.

If you have local changes on your master that aren't reflected on origin, you might want git rebase origin/master to make sure your commits are 'on top'.

Carl Norum
  • 219,201
  • 40
  • 422
  • 469
  • 1
    Do I need to `git rebase origin/master` before `git merge orgin/master`? I'm asking only for the case when I have local changes on `master` that aren't reflected on `origin`. – IsmailS Sep 10 '13 at 08:44
  • 1
    You need to do one or the other, not both. Which to choose depends on the outcome you're after, but `rebase` is usually what you want. – Carl Norum Sep 10 '13 at 08:52
17

I typically do this:

git merge --ff-only @{u}

Which says, "only do a fast-forward merge from the upstream tracking branch." It's nice because if it fails, then I know I introduced something on master that is not upstream. I have that aliased to ff, just to make it easier to type.

If there are changes, and you simply want to merge them, you can do:

git merge @{u}

Which will merge in the upstream branch. However, if you'd like a cleaner history (and avoid the "Merging 'origin/master' into 'master'" commits, then you might want to consider rebasing instead:

git rebase @{u}

Of course, you can use origin/master instead of @{u} in any of these examples.

Stefan Zobel
  • 3,182
  • 7
  • 28
  • 38
John Szakmeister
  • 44,691
  • 9
  • 89
  • 79
9

The command

git pull $some_url

is equivalent to

git fetch $some_url
git merge FETCH_HEAD

See also the git-pull(1) man page for details, especially the first two paragraphs of the description.

maxschlepzig
  • 35,645
  • 14
  • 145
  • 182
0

To fetch a specific branch:
1. git fetch <branch URL><branch name> 

2. git pull = git fetch + git merge

3(a). git merge origin/master The origin/master and master branches now point to the same commit, and you are synchronized with the upstream developments.

(OR)

3(b). git merge FETCH_HEAD

Prasenjit Mahato
  • 1,174
  • 15
  • 10