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。完整格式是：

 

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

 

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

 

git pull origin develop:develop

 

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

 

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）直接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的哪些节点都消失了。

二、放弃本地修改 的改法

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