git pull详细用法

git pull命令的作用是，取回远程主机某个分支的更新，再与本地的指定分支合并。它的完整格式稍稍有点复杂。

$ git pull <远程主机名> <远程分支名>:<本地分支名>

比如，取回origin主机的next分支，与本地的master分支合并，需要写成下面这样。

$ git pull origin next:master

如果远程分支是与当前分支合并，则冒号后面的部分可以省略。

$ git pull origin next

上面命令表示，取回origin/next分支，再与当前分支合并。实质上，这等同于先做git fetch，再做git merge。

$ git fetch origin
$ git merge origin/next

在某些场合，Git会自动在本地分支与远程分支之间，建立一种追踪关系(tracking)。比如，在git clone的时候，所有本地分支默认与远程主机的同名分支，建立追踪关系，也就是说，本地的master分支自动”追踪”origin/master分支。

Git也允许手动建立追踪关系。

git branch --set-upstream master origin/next

上面命令指定master分支追踪origin/next分支。

如果当前分支与远程分支存在追踪关系，git pull就可以省略远程分支名。

$ git pull origin

上面命令表示，本地的当前分支自动与对应的origin主机”追踪分支”(remote-tracking branch)进行合并。

如果当前分支只有一个追踪分支，连远程主机名都可以省略。

$ git pull

上面命令表示，当前分支自动与唯一一个追踪分支进行合并。

另外，我们在使用git pull命令的时候，可以使用—rebase参数，即git pull —rebase,这里表示把你的本地当前分支里的每个提交(commit)取消掉，并且把它们临时 保存为补丁(patch)(这些补丁放到”.git/rebase”目录中),然后把本地当前分支更新 为最新的”origin”分支，最后把保存的这些补丁应用到本地当前分支上。

$ git pull --rebase <远程主机名> <远程分支名>:<本地分支名>

——————————————————以下转自知乎————————————————————
作者：larmbr宇
链接：http://www.zhihu.com/question/23586864/answer/25052969
来源：知乎
著作权归作者所有，转载请联系作者获得授权。

git pull的默认行为是git fetch + git merge,
git pull —rebase则是git fetch + git rebase.

从目的来说，两者没差别，运行之后， 你能获得一样的code base。
但从版本管理角度，这两者有各自的使用意义。

git merge:
简单来说，它把两条不同分支历史的所有提交合并成一条线，并在“末端”打个结，即生成一次合并提交。最后形成一条单一的提交线。

git rebase:
根据参数的不同，行为有些差别。但总的来说，它相当于把分叉的两条历史提交线中的一条，每一次提交都捡选出来， 在另一条提交线上提交。最后也形成一条单一的提交线。

对比来看，git merge多了一次提交—“合并提交”。git rebase则没有。
不过，git merge保存了两条线的历史。而git rebase则会破坏历史。因为每一次rebase, 提交id会变化(因为父提交变了，而父提交Id是用来生成提交id的内容之一）。

那谁好谁坏呢？没有绝对答案。得看使用者的角色。举个例子。

git的使用者中，典型的是Linux内核社区。 他们采用的是一种叫司令官与副官工作流(dictator and lieutenat workflow)。在这种模式中, 有若干个管理员, 分别负责项目中的特定部分，是为副官(lieutenant); 所有这些管理员头上还有一位负责统筹的总管理员，是为司令官(dictator)。司令官维护的版本库用于提供给所有项目协作者(不仅仅是副官, 还可以包括来自全球的”士兵”), 以供他们拉取集成的项目代码。

Linus本人就是上述中的司令官了，每次他从其他子系统维护者那拉代码时，用的是git merge.. 原因是，git merge生成一次合并提交，这就是一个明显的标志，告诉其他人，这次从某人合并来了什么代码，为什么要合并这些代码。等等。他不能使用git rebase, 原因是这样会改变历史。比如某一次在某子系统维护者处的ID是AAAA…..AAAAA, 他希望进了Linus代码库后还是这个ID，这样他在邮件或其他地方可以引用这个ID，不用担心变化。但是，如果使用git rebase, 这个提交ID是会变的，这样他引用的ID就没用了。

作为个人开发者，一直follow着Linus的版本库, 叫mainline，那么可以自由地选择git merge或git rebase, 因为你这只有单一一条时间线，没差别。但是，一旦你开始作了很多次本地的代码修改，在本地生成了提交，这就意味着你和mainline分叉了，这样，你下次更新代码时，一定要选择git
rebase, 把你的自己的提交rebase到mainline上， 即始终保持你自己的代码在mainline之上。不推荐使用git merge, 因为你的版本库是当作mainline镜像，你一merge就变成跟mainline不同了，下次再更新代码就会冲突。