github常用技巧记录

1. 使用git pull文件时和本地文件冲突怎么办？

1、先将本地修改存储起来$ git stash这样本地的所有修改就都被暂时存储起来 。是用git stash list可以看到保存的信息：git stash暂存修改git stash暂存修改其中stash@{0}就是刚才保存的标记。2、pull内容暂存了本地修改之后，就可以pull了。$ git pull3、还原暂存的内容$ git stash pop stash@{0}系统提示如下类似的信息：Auto-merging c/environ.cCONFLICT (content): Merge conflict in c/environ.c意思就是系统自动合并修改的内容，但是其中有冲突，需要解决其中的冲突。4、解决文件中冲突的的部分打开冲突的文件，会看到类似如下的内容：git冲突内容git冲突内容其中Updated upstream 和=====之间的内容就是pull下来的内容，====和stashed changes之间的内容就是本地修改的内容。碰到这种情况，git也不知道哪行内容是需要的，所以要自行确定需要的内容。解决完成之后，就可以正常的提交了。

2. git-pull之后如何查看拉下来的文件有那些修改
git pull对于拉下来的修改文件自动对其进行git add /rm 及git commit 操作。所以拉下来的文件有那些修改，查看的方式可把它们归结于上一次提交的比较。
git diff HEAD 显示工作目录与git仓库之间的差异，而git diff HEAD^ 则显示上一次提交之前工作目录与git仓库之间的差异。所以我们在git pull后，可以通过git diff HEAD^ 来查看拉下来的文件有那些具体的修改。

git diff 显示工作目录与索引文件之间的差异
git diff –cached显示索引文件与git仓库之间的差异

3. 分支合并

在问题 #53 相关的工作完成之后，可以合并回 master 分支。实际操作同前面合并 hotfix 分支差不多，只需回到 master 分支，运行 git merge 命令指定要合并进来的分支：

$ git checkout master$ git merge iss53Auto-merging READMEMerge made by the 'recursive' strategy. README | 1 + 1 file changed, 1 insertion(+)

请注意，这次合并操作的底层实现，并不同于之前 hotfix 的并入方式。因为这次你的开发历史是从更早的地方开始分叉的。由于当前 master 分支所指向的提交对象（C4）并不是 iss53 分支的直接祖先，Git 不得不进行一些额外处理。就此例而言，Git 会用两个分支的末端（C4 和 C5）以及它们的共同祖先（C2）进行一次简单的三方合并计算。图 3-16 用红框标出了 Git 用于合并的三个提交对象：

图 3-16. Git 为分支合并自动识别出最佳的同源合并点。
这次，Git 没有简单地把分支指针右移，而是对三方合并后的结果重新做一个新的快照，并自动创建一个指向它的提交对象（C6）（见图 3-17）。这个提交对象比较特殊，它有两个祖先（C4 和 C5）。

值得一提的是 Git 可以自己裁决哪个共同祖先才是最佳合并基础；这和 CVS 或 Subversion（1.5 以后的版本）不同，它们需要开发者手工指定合并基础。所以此特性让 Git 的合并操作比其他系统都要简单不少。

图 3-17. Git 自动创建了一个包含了合并结果的提交对象。
既然之前的工作成果已经合并到 master 了，那么 iss53 也就没用了。你可以就此删除它，并在问题追踪系统里关闭该问题。

$ git branch -d iss53