git pull和git merge区别&&Git冲突：commit your changes or stash them before you can merge. 解决办法

http://blog.csdn.net/sidely/article/details/40143441

原文： http://www.tech126.com/git-fetch-pull/

Git中从远程的分支获取最新的版本到本地有这样2个命令：
1. git fetch：相当于是从远程获取最新版本到本地，不会自动merge

git fetch origin master
git log -p master..origin/master
git merge origin/master

以上命令的含义：
   首先从远程的origin的master主分支下载最新的版本到origin/master分支上
   然后比较本地的master分支和origin/master分支的差别
   最后进行合并
   上述过程其实可以用以下更清晰的方式来进行：

git fetch origin master:tmp （把远程的master copy到本地的tmp）
git diff tmp  （这里是比较当前分支和tmp分支，会显示所有不同之处，有时只想显示文件列表，git diff branch1 branch2 --stat

加上 --stat 是显示文件列表, 否则是文件内容diff

git diff tmp 文件路径 ，具体比较某个文件

）
git merge tmp (把本地的和tmp分支合并）

从远程获取最新的版本到本地的tmp分支上
   之后再进行比较合并

 

 

 

Git小技巧：如何从其他分支merge个别文件

git checkout source_branch <paths>...

但严格来说，这似乎不是合并，而是用另一分支"source_branch"的指定文件直接覆盖当前分支的相应文件。

注意：在使用git checkout某文件到当前分支时，会将当前分支的对应文件强行覆盖。

如果不确定新文件是否能完全覆盖master中的旧文件，可以新建一个master分支mastertmp，将变化的文件checkout到mastertmp，然后让master与mastertmp进行合并。

有个问题:

root@i :/opt/nginx/html/  git fetch origin master:tmp
remote: Counting objects: 12, done.
remote: Compressing objects: 100% (11/11), done.
remote: Total 12 (delta 5), reused 0 (delta 0)
Unpacking objects: 100% (12/12), done.
From ssh://bitbucket.org/ 
05eb1e3..c2cd20f master -> tmp
05eb1e3..c2cd20f master -> origin/master

为什么fetch到tmp分支上会跟新到master分支。

2. git pull：相当于是从远程获取最新版本并merge到本地

git pull origin master

上述命令其实相当于git fetch 和 git merge
在实际使用中，git fetch更安全一些
因为在merge前，我们可以查看更新情况，然后再决定是否合并

结束

git pull的作用是，从远程库中获取某个分支的更新，再与本地指定的分支进行自动merge。完整格式是：

1. $ git pull <远程库名> <远程分支名>:<本地分支名>

比如，取回远程库中的develop分支，与本地的develop分支进行merge，要写成：

1. git pull origin develop:develop

如果是要与本地当前分支merge，则冒号后面的<本地分支名>可以不写。

1. git pull origin develop

--

git命令之git fetch的用法

理解 fetch 的关键, 是理解 FETCH_HEAD.

这里需要解释下什么是FETCH_HEAD??

FETCH_HEAD指的是: 某个branch在服务器上的最新状态'.
每一个执行过fetch操作的项目'都会存在一个FETCH_HEAD列表, 
这个列表保存在 .git/FETCH_HEAD 文件中, 其中每一行对应于远程服务器的一个分支.
当前分支指向的FETCH_HEAD, 就是这个文件第一行对应的那个分支.

一般来说, 存在两种情况:

• 如果没有显式的指定远程分支, 则远程分支的master将作为默认的FETCH_HEAD.

• 如果指定了远程分支, 就将这个远程分支作为FETCH_HEAD.

常见的git fetch 使用方式包含以下四种:

• git fetch

这一步其实是执行了两个关键操作:
- 创建并更新所有远程分支的本地远程分支.
- 设定当前分支的FETCH_HEAD为远程服务器的master分支 (上面说的第一种情况)

需要注意的是: 和push不同, fetch会自动获取远程`新加入'的分支.

• git fetch origin

同上, 只不过手动指定了remote.

• git fetch origin branch1

设定当前分支的 FETCH_HEAD' 为远程服务器的branch1分支`.

注意: 在这种情况下, 不会在本地创建本地远程分支, 这是因为:

这个操作是git pull origin branch1的第一步, 而对应的pull操作,并不会在本地创建新的branch.

一个附加效果是:

这个命令可以用来测试远程主机的远程分支branch1是否存在, 如果存在, 返回0, 如果不存在, 返回128, 抛出一个异常.

• git fetch origin branch1:branch2

只要明白了上面的含义, 这个就很简单了,

• 首先执行上面的fetch操作

• 使用远程branch1分支在本地创建branch2(但不会切换到该分支), 
  如果本地不存在branch2分支, 则会自动创建一个新的branch2分支, 
  如果本地存在branch2分支, 并且是`fast forward', 则自动合并两个分支, 否则, 会阻止以上操作.

• git fetch origin :branch2

等价于: git fetch origin master:branch2

 （

https://ruby-china.org/topics/4768

而理解 fetch 的关键, 是理解 FETCH_HEAD.

这里需要解释下什么是FETCH_HEAD??

FETCH_HEAD指的是: 某个branch在服务器上的最新状态'. 每一个执行过fetch操作的项目'都会存在一个FETCH_HEAD列表, 这个列表保存在 .git/FETCH_HEAD 文件中, 其中每一行对应于远程服务器的一个分支. 当前分支指向的FETCH_HEAD, 就是这个文件第一行对应的那个分支.

一般来说, 存在两种情况:

• 如果没有显式的指定远程分支, 则远程分支的master将作为默认的FETCH_HEAD.

• 如果指定了远程分支, 就将这个远程分支作为FETCH_HEAD.

常见的git fetch 使用方式包含以下四种:

• git fetch

这一步其实是执行了两个关键操作:

• 创建并更新所有远程分支的本地远程分支.
• 设定当前分支的FETCH_HEAD为远程服务器的master分支 (上面说的第一种情况)

需要注意的是: 和push不同, fetch会自动获取远程`新加入'的分支.

• git fetch origin

同上, 只不过手动指定了remote.

• git fetch origin branch1

设定当前分支的 FETCH_HEAD' 为远程服务器的branch1分支`.

注意: 在这种情况下, 不会在本地创建本地远程分支, 这是因为:

这个操作是git pull origin branch1的第一步, 而对应的pull操作,并不会在本地创建新的branch.

一个附加效果是:

这个命令可以用来测试远程主机的远程分支branch1是否存在, 如果存在, 返回0, 如果不存在, 返回128, 抛出一个异常.

• git fetch origin branch1:branch2

只要明白了上面的含义, 这个就很简单了,

• 首先执行上面的fetch操作

• 使用远程branch1分支在本地创建branch2(但不会切换到该分支), 如果本地不存在branch2分支, 则会自动创建一个新的branch2分支, 如果本地存在branch2分支, 并且是`fast forward', 则自动合并两个分支, 否则, 会阻止以上操作.

• git fetch origin :branch2

等价于: git fetch origin master:branch2

git pull

只要理解了git fetch, git pull就太简单了.

git pull 等价于以下两步:

• 经命令中的pull换成fetch, 执行之...
• git merge FETCH_HEAD

唯一需要提及的一点是:

我认为pull操作, 不应该涉及三方合并 或 衍合 操作 换个说法: pull 应该总是 fast forward 的. 为了达到这样一个效果, 在真正push操作之前, 我倾向于使用衍合, 在本地对代码执行合并操作.

）

 

用git pull来更新代码的时候，遇到了下面的问题：

error: Your local changes to the following files would be overwritten by merge:
    xxx/xxx/xxx.php
Please, commit your changes or stash them before you can merge.
Aborting

出现这个问题的原因是其他人修改了xxx.php并提交到版本库中去了，而你本地也修改了xxx.php，这时候你进行git pull操作就好出现冲突了，解决方法，在上面的提示中也说的很明确了。

1、保留本地的修改 的改法

1）直接commit本地的修改

2）通过git stash

git stash
git pull
git stash pop

通过git stash将工作区恢复到上次提交的内容，同时备份本地所做的修改，之后就可以正常git pull了，git pull完成后，执行git stash pop将之前本地做的修改应用到当前工作区。

git stash: 备份当前的工作区的内容，从最近的一次提交中读取相关内容，让工作区保证和上次提交的内容一致。同时，将当前的工作区内容保存到Git栈中。

git stash pop: 从Git栈中读取最近一次保存的内容，恢复工作区的相关内容。由于可能存在多个Stash的内容，所以用栈来管理，pop会从最近的一个stash中读取内容并恢复。

git stash list: 显示Git栈内的所有备份，可以利用这个列表来决定从那个地方恢复。

git stash clear: 清空Git栈。此时使用gitg等图形化工具会发现，原来stash的哪些节点都消失了。

2、放弃本地修改 的改法

git reset --hard
git pull
转自：http://www.letuknowit.com/post/144.html