github常用技巧记录
2016-01-06 16:21
330 查看
1. 使用git pull文件时和本地文件冲突怎么办?
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 命令指定要合并进来的分支:
请注意,这次合并操作的底层实现,并不同于之前 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
1、先将本地修改存储起来 $ git stash 这样本地的所有修改就都被暂时存储起来 。是用git stash list可以看到保存的信息: git stash暂存修改 git stash暂存修改 其中stash@{0}就是刚才保存的标记。 2、pull内容 暂存了本地修改之后,就可以pull了。 $ git pull 3、还原暂存的内容 $ git stash pop stash@{0} 系统提示如下类似的信息: Auto-merging c/environ.c CONFLICT (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 iss53 Auto-merging README Merge 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
相关文章推荐
- java 中的多态的演示
- 【C++11新特性】 auto关键字
- Python urllib2 使用
- 静态库单例问题
- struts2自带拦截器
- 借助github搭建自己的博客
- 实例导航条代码
- *圣思园java se培训总结(103-)(线程间相互作用)
- c++获取随机数
- java中的方法重载 overload
- matlab中figure的坐标轴label、title、xticklabel的旋转
- C++中BMP文件头函数编写(24bit真彩、8位灰度和8位伪彩色)
- Java8 lambda表达式的实现探索
- Java Script 第十一节课 Java Script的中的函数-通过function关键
- 学习资料网址
- 简单 python 爬虫(一)
- (Java基础--反射)理解反射的概念
- java 的synchronized 机制详细介绍
- 【python学习笔记】如何说明import语句对模块导入的检查?
- eclipse安装maven插件时出错