本文有点长而且有点乱，但就像Mark Twain&的笑话里说的那样：我没有时间让它更短些。在Git的邮件列表里有很多，我会尽量把其中相关的观点列在下面。
我最常说的关于git使用的一个经验就是：
不要用git pull，用git fetch和git merge代替它。
git pull的问题是它把过程的细节都隐藏了起来，以至于你不用去了解git中各种类型分支的区别和使用方法。当然，多数时候这是没问题的，但一旦代码有问题，你很难找到出错的地方。看起来git pull的用法会使你吃惊，简单看一下git的使用文档应该就能说服你。
将下载（fetch）和合并（merge）放到一个命令里的另外一个弊端是，你的本地工作目录在未经确认的情况下就会被远程分支更新。当然，除非你关闭所有的安全选项，否则git pull在你本地工作目录还不至于造成不可挽回的损失，但很多时候我们宁愿做的慢一些，也不愿意返工重来。
分支(Branches)
在说git pull之前，我们需要先澄清分支的概念（branches）。很多人像写代码似的用一行话来描述分支是什么，例如:
准确而言，分支的概念不是一条线，而类似于开发中的有向无环图分支类似于一个重量级的大对象集合。
我认为你应该这样来理解分支的概念：它是用来标记特定的代码提交，每一个分支通过SHA1sum值来标识，所以对分支进行的操作是轻量级的--你改变的仅仅是SHA1sum值。
这个定义或许会有意想不到的影响。比如，假设你有两个分支，“stable” 和 “new-idea”, 它们的顶端在版本 E 和 F:
A-----C----E (&stable&)
B-----D-----F (&new-idea&)
所以提交(commits) A, C和 E 属于“stable”，而&A, B, D 和 F 属于 “new-idea”。如果之后你用下面的命令&将“new-idea”&merge 到 “stable” ：
git checkout stable
# Change to work on the branch &stable&
git merge new-idea
# Merge in &new-idea&
…那么你会得到这个：
A-----C----E----G (&stable&)
B-----D-----F (&new-idea&)
要是你继续在“new idea” 和“stable”分支提交, 会得到：
A-----C----E----G---H (&stable&)
B-----D-----F----I (&new-idea&)
因此现在A, B, C, D, E, F, G 和 H 属于 “stable”，而A, B, D, F 和 I 属于 “new-idea”。
当然了，分支确实有些特殊的属性——其中最重要的是，如果你在一个分支进行作业并创建了一个新的提交(commits)，该分支的顶端将前进到那个提交(commits)。这正是你所希望的。当用git merge&进行合并(merge)的时候，你只是指定了要合并到当前分支的那个并入分支，以及当前分支的当前进展。
另一个表明使用分支会有很大帮助的观点的常见情形是：假设你直接工作在一个项目的主要分支（称为“主版本”），当你意识到你所做的可能是一个坏主意时已经晚了，这时你肯定宁愿自己是工作在一个主题分支上。如果提交图看起来像这样：
last version from another repository
M---N-----O----P---Q (&master&)
那么你把你的工作用下面的一组命令分开做（如图显示的是执行它们之后所更改的状态）：
git branch dubious-experiment
M---N-----O----P---Q (&master& and &dubious-experiment&)
git checkout master
# Be careful with this next command: make sure &git status& is
# clean, you're definitely on &master& and the
# &dubious-experiment& branch has the commits you were working
# on first...
git reset --hard &SHA1sum of commit N&
(&master&)
M---N-------------O----P---Q (&dubious-experiment&)
git pull # Or something that updates &master& from
# somewhere else...
M--N----R---S (&master&)
O---P---Q (&dubious-experiment&)
这是个看起来我最终做了很多的事情。
分支这个术语不太容易理解,而且在git的开发过程中发生了很多变化。但简单来说git的分支只有两种：
a）“本地分支(local branches)” ，当你输入“git branch”时显示的。例如下面这个小例子：
$ git branch
b)“远程跟踪分支(Remote-tracking branches)” ，当你输入“git branch -r”是显示的，如:
$ git branch -r
cognac/master
fruitfly/server
origin/albert
origin/ant
origin/contrib
origin/cross-compile
从上面的输出可以看到，跟踪分支的名称前有一个“远程的”标记名称（如&:origin, cognac, fruitfly）后面跟一个“／”，然后远程仓库里分支的真正名称。（“远程名称”是一个代码仓库别名，和本地目录或URL是一个含义，你可以通过&git remote&命令自由定义额外的“远程名称”。但“git clone”命令默认使用的是“origin”这个名称。）
如果你对分支在本地是如何存储感兴趣的话，看看下面文件：&
& .git/refs/head/[本地分支]& .git/refs/remotes/[正在跟踪的分支]
两种类型的分支在某些方面十分相似-它们都只是在本地存储一个表示提交的SHA1校验和。（我强调“本地”，因为许多人看到&origin/master& 就认为这个分支在某种意义上说是不完整的，没有访问远端服务器的权限- 其实不是这种情况。）&
不管如何相似，它们还是有一个特别重大的区别：&
& 更改远端跟踪分支的安全方法是使用git fetch或者是作为git-push副产品，你不能直接对远端跟踪分支这么操作。相反，你总得切换到本地分支，然后创建可移动到分支顶端的新提交 。
因此，你对远端跟踪分支最多能做的是下面事情中的一件：&
&使用git fetch 更新远端跟踪分支&合并远端跟踪分支到当前分支&根据远端跟踪分支创建本地分支
基于远程跟踪分支创建本地分支
如果你想基于远程跟踪分支创建本地分支（在本地分支上工作）,你可以使用如下命令：git branch –track或git checkout –track -b，两个命令都可以让你切换到新创建的本地分支。例如你用git branch -r命令看到一个远程跟踪分支的名称为“origin/refactored”是你所需要的，你可以使用下面的命令：
git checkout --track -b refactored origin/refactored
在上面的命令里，“refactored”是这个新分支的名称，“origin/refactored”则是现存远程跟踪分支的名称。（在git最新的版本里，例子中‘-track’选项已经不需要了，如果最后一个参数是远程跟踪分支，这个参数会被默认加上。）
“–track”选项会设置一些变量，来保持本地分支和远程跟踪分支的相关性。他们对下面的情况很有用：
git pull命令下载新的远程跟踪分支之后，可以知道合并到哪个本地分支里使用git checkout检查本地分支时，可以输出一些有用的信息：
Your branch and the tracked remote branch 'origin/master'
have diverged, and respectively have 3 and 384 different
commit(s) each.
Your branch is behind the tracked remote branch
'origin/master' by 3 commits, and can be fast-forwarded.
允许使用的配置变量是：“branch.&local-branch-name&.merge”和“branch.&local-branch-name&.remote”，但通常情况下你不用考虑他们的设置。
当从远程代码仓库创建一个本地分支之后，你会注意到，“git branch -r”能列出很多远程跟踪分支，但你的电脑上只有一个本地分支，你需要给上面的命令设置一个参数，来指定本地分支和远程分支的对应。
有一些术语上的说法容易混淆需要注意一下：“track”在当作参数&-track&使用时，意思指通过本地分支对应一个远程跟踪分支。在远程跟踪分支中则指远程代码仓库中的跟踪分支。有点绕口。。。
下面我们来看一个例子，如何从远程分支中更新本地代码，以及如何把本地分支推送到一个新的远程仓库中。
从远端仓库进行更新
如果我想从远端的源仓库更新到本地的代码仓库，可以输入“git fetch origin”的命令，该命令的输入类似如下格式：
remote: Counting objects: 382, done.
remote: Compressing objects: 100% (203/203), done.
remote: Total 278 (delta 177), reused 103 (delta 59)
Receiving objects: 100% (278/278), 4.89 MiB | 539 KiB/s, done.
Resolving deltas: 100% (177/177), completed with 40 local objects.
From ssh://longair@pacific.mpi-cbg.de/srv/git/fiji
3036acc..9eb5e40
debian-release- -& origin/debian-release-
* [new branch]
debian-release- -& origin/debian-release-
* [new branch]
debian-release- -& origin/debian-release-
3d619e7..6260626
-& origin/master
最重要的是这两行：
3036acc..9eb5e40
debian-release- -& origin/debian-release-
* [new branch]
debian-release- -& origin/debian-release-
第一行表明远端的origin/debian-release-分支的提交(commit)ID已经从3036acc更新为9eb5e40。箭头前的部分是远端分支的名称。第二行是我们采取的动作，创建远程跟踪分支（如果远程仓库有新的tags，git fetch也会一并下载到本地）。
前面那些行显示出“git fetch”命令会将哪些文件下载到本地，这些文件一旦下载到本地之后，就可以在本地进行任意操作了。
“git fetch”命令执行完毕之后，还不会立即将下载的文件合并到你当前工作目录里，这就给你了一个选择下一步操作的机会，要是想将从远程分支下载的文件更新到你的工作目录里，你需要执行一个“合并（merge）”操作。例如，我当前的本地分支为”master“（执行git checkout master后），这时我想执行合并操作：
git merge origin/master
(&几句题外话：合并的时候有可能你还没有对远程分支提交过任何的更改，或者可能是一个复杂的合并。)
如果你只是想看看本地分支和远程分支的差异，你可以使用下面的命令：
git diff master origin/master
单独进行下载和合并是一个好的做法，你可以先看看下载的是什么，然后再决定是否和本地代码合并。而且分开来做，可以清晰的区别开本地分支和远程分支，方便选择使用。
把你的变更推送到一个远程仓库
如何通过其他的方式呢? 假设你对 “experimental”分支做了变更并且希望把他push到&origin&远程仓库中去. 你可以这样做:
git push origin experimental
你可能将会收到:远程仓库无法fast-forward该分支的错误信息, 这将意味着可能有别人push了不同的变更到了这个分支上.所以,你需要fetch和merge别人的变更并再次尝试push操作.
扩展阅读： 如果这个分支在远程仓库里对应不同的名称（如:experiment-by-bob）,你应该这么做：&
git push origin experimental:experiment-by-bob
在旧版本的git里，如果“experiment-by-bob”不存在，命令应该这么写：&
git push origin experimental:refs/heads/experiment-by-bob
这样会首先创建远程分支。但git 1.6.1.2应该就不用这么做了。参加下面Sitaram’s的评论。&
&如果本地分支和远程分支名称相同，不需要特殊说明系统将会自动创建这个分支,就像常规的git push操作一样。&
在实际应用中，保持名称相同可以减少混淆，因此“本地名称和远程名称”作为“refspec”参数，我们不会进行更多的讨论。
git push的操作不会牵扯远程跟踪分支（origin/experimental），只有在你下次进行git
fetch时才会被更新。
上面这个说法不对，根据Deskin Miller的评论纠正：当推送到对应的远程分支后，你的远程跟踪分支就会被更新。
为什么不用 git 的 pull？
虽然&git pull&大部分时候是好的，特别是如果你用CVS类型的方式使用Git时，它可能正适合你。然而，如果你想用一个更地道的方式（建立很多主题分支，当你需要时随时改写本地历史，等等）使用Git，那么习惯把&git fetch&和&git merge&分开做会有很大帮助。
&&相关文章推荐
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：8773次
排名：千里之外
转载：31篇
(1)(1)(1)(3)(4)(3)(4)(1)(2)(1)(2)(1)(3)(2)(3)(1)使用git fetch和git pull都可以更新远程仓库的代码到本地，但是它们之间还是有区别。今天搜了一下git pull和fetch，发现信息量很大，牵扯到git中很多概念，以我这种智商估计要完全理解很困难，所以先声明一下，下面的内容是我综合了网上的资料后，自己的理解，如有误导，敬请谅解。
首先，我搜索了git pull和git fetch的区别，网上的帖子很多，我主要参考了这个帖子，我摘抄下主要内容。
git fetch origin master
git log -p master..origin/master
git merge origin/master
从远程的origin仓库的master主分支更新最新的版本到origin/master分支上
比较本地的master分支和origin/master分支的差别
合并内容到本地master分支
另外一种fetch使用方式参考我之前的文章。
git pull origin master
相当于git fetch 和 git merge，即更新远程仓库的代码到本地仓库，然后将内容合并到当前分支。
所以，简单的说git pull相当于git fetch后再做一个git merge。那么它们具体的区别如何分析呢，这就需要我们再认识下git了，先看看下面这张图：
我们知道，git其实有好几个区，工作区（workspace）、暂存区（index）、本地仓库（local repository），当然还有远程仓库（remote repository）。远程仓库为我们保存一份代码拷贝，如github，而工作区、暂存区和本地仓库都在本地，这就是为什么没有网络我们也照样使用git提交（commit）代码更新，因为提交仅是提交到本地仓库，待有网络之后可以再推送（push）到远程仓库。
正如上图所示，git fetch是将远程仓库的更新获取到本地仓库，不影响其他区域。而git pull则是一次性将远程仓库的代码更新到工作区（同时也会更新本地仓库）。
通常来说，git fetch和merge与git pull的区别已经很明显了，但是如果想再了解下git是如何操作的，则需要我们了解下分支这个git的强大特性（分支的概念确实太牛逼了，我不确定我的理解是否是正确的）。
分支（branches）是用来标记特定的代码提交，每一个分支通过SHA1sum值来标识，所以对分支进行的操作是轻量级的——你改变的仅仅是SHA1sum值。所以为什么git提倡大家多使用分支，因为它即轻量级又灵活。简单的说，分支有两种：
本地分支(local branches)” ，当你输入“git branch”时显示的：
$ git branch
远程分支(remote branches)” ，当你输入“git branch -r”是显示的：
$ git branch -r
origin/master
如果你对分支在本地是如何存储感兴趣的话，看看项目中的下面文件，文件里面存的就是一个SHA1sum值：
.git/refs/head/[本地分支]
.git/refs/remotes/[正在跟踪的分支]
我们来看看远程分支，这本书描述的非常好。远程分支（remote branch）是对远程仓库中的分支的索引。它们是一些无法移动的本地分支；只有在 Git 进行网络交互时才会更新。远程分支就像是书签，提醒着你上次连接远程仓库时上面各分支的位置。
我们用 (远程仓库名)/(分支名) 这样的形式表示远程分支。比如我们想看看上次同 origin 仓库通讯时 master 分支的样子，就应该查看 origin/master 分支。如果你和同伴一起修复某个问题，但他们先推送了一个 iss53 分支到远程仓库，虽然你可能也有一个本地的 iss53 分支，但指向服务器上最新更新的却应该是 origin/iss53 分支。
下面我把Pro Git中的例子摘抄过来。假设你们团队有个地址为
的 Git 服务器。如果你从这里克隆，Git 会自动为你将此远程仓库命名为 origin，并下载其中所有的数据，建立一个指向它的 master 分支的指针，在本地命名为 origin/master，但你无法在本地更改其数据。接着，Git 建立一个属于你自己的本地 master 分支，始于 origin 上 master 分支相同的位置，你可以就此开始工作：
这样，我们在本地仓库的本地分支和远程分支都有了，并且起始于同一位置。
如果你在本地 master 分支做了些改动（在本地工作区commit了代码到本地仓库），与此同时，其他人向
推送了他们的更新，那么服务器上的 master 分支就会向前推进，而与此同时，你在本地的提交历史正朝向不同方向发展。不过只要你不和服务器通讯，你的 origin/master 指针仍然保持原位不会移动：
注意这里的本地分支已经前移，而远程分支还保持不动，而远程仓库的master其实也已经前移，所以可以说本地的远程分支origin/master是过时的。
可以运行 git fetch origin 来同步远程服务器上的数据到本地。该命令首先找到 origin 是哪个服务器（本例为 ），从上面获取你尚未拥有的数据，更新你本地的数据库（仓库），然后把 origin/master 的指针移到它最新的位置上：
现在大家能看到git fetch的作用了吗？
接下来还没完，我们来看看git的高级玩儿法。为了演示拥有多个远程分支（在不同的远程服务器上）的项目是如何工作的，我们假设你还有另一个仅供你的敏捷开发小组使用的内部服务器 git.。可以用第二章中提到的 git remote add 命令把它加为当前项目的远程分支之一。我们把它命名为 teamone，以便代替完整的 Git URL 以方便使用：
注意这里是多个远程分支，不同的远程服务器。
现在你可以用 git fetch teamone 来获取小组服务器上你还没有的数据了。由于当前该服务器上的内容是你 origin 服务器上的子集，Git 不会下载任何数据，而只是简单地创建一个名为 teamone/master 的远程分支，指向 teamone 服务器上 master 分支所在的提交对象 31b8e：
由此你在本地就有了两个远程分支，作为指向两个远程服务器上 master 分支的索引。
好了，不扯远了，总结下git fetch和git pull：
git fetch is the command that says “bring my local copy of the remote repository up to date.”
git pull says “bring the changes in the remote repository where I keep my own code.”
由于git pull把过程的细节都隐藏了起来，以至于你不用去了解git中各种类型分支的区别和使用方法。当然，多数时候这是没问题的，但一旦代码有问题，你很难找到出错的地方。看起来git pull的用法会使你吃惊，简单看一下git的使用文档应该就能说服你。
将下载（fetch）和合并（merge）放到一个命令里的另外一个弊端是，你的本地工作目录在未经确认的情况下就会被远程分支更新。
单独进行下载和合并是一个好的做法，你可以先看看区别（diff），然后再决定是否和本地代码合并。而且分开来做，可以清晰的区别开本地分支和远程分支，方便选择使用。所以尽量少用git pull，多用git fetch和merge。
- 15,247 views - 5,909 views - 4,074 views - 3,833 views - 3,741 views
“说不定我一生涓滴意念，侥幸汇成河。然后我俩各自一端，望着大河弯弯，终于敢放胆，嘻皮笑脸面对，人生的难。”Git-Subversion对比 | Git索引 | 猴子都能懂的GIT入门| 贝格乐（Backlog）
Git-Subversion对比
Git-Subversion对比
Git-Subversion命令对比表
Git与Subversion的命令对比表
Subversion
复制数据库
svn checkout
git commit
svn commit
查看提交的详细记录
git status
svn status
git checkout / git reset
svn revert (※1)
git branch
svn copy (※2)
git checkout
svn switch
svn copy (※2)
git pull / git fetch
svn update
反映到远端
svn commit (※3)
忽略档案目录
.gitignore
.svnignore
※1. SVN的revert是用来取消修改，但Git的revert是用来消除提交。所以即使是同样的命令，在SVN和Git里的含义是不同的。
※2. SVN的分支与标签在构造上是相同的，但在Git其构造明显是不一样的。
※3. SVN没有本地数据库/远程数据库的概念，所以提交会马上反映到远程里。但Git的本地数据库和远程数据库的反映方法是不一样的。