git总结

时间：2016-11-14 09:36:45 阅读：492 评论：0 收藏：0 [点我收藏+]

1.以下是自己画的一个流程图,先对git的操作有个直观了解

2.分析下git中文件是怎么存储的
在我们的项目中有个.git文件夹,里面的objects文件夹内存放了很多文件，他们都使用 sha-1 的前两位创建了文件夹，剩下的38位为文件名。我们先称呼这些文件为 obj 文件
 
这些obj 文件保存了我们代码提交的所有记录。分为四种类型，分别是 blob、tree、commit、tag。
1.blob: 用来存放项目文件的内容，但是不包括文件的路径、名字、格式等其它描述信息。项目的任意文件的任意版本都是以blob的形式存放的。
2.tree 用来表示目录。我们知道项目就是一个目录，目录中有文件、有子目录。因此 tree 中有 blob、子tree，且都是使用 sha-1值引用的。这是与目录对应的。从顶层的 tree 纵览整个树状的结构，叶子结点就是blob，表示文件的内容，非叶子结点表示项目的目录，顶层的 tree 对象就代表了当前项目的快照。
3.commit: 表示一次提交，有parent字段，用来引用父提交。指向了一个顶层 tree，表示了项目的快照，还有一些其它的信息，比如上一个提交，committer、author、message 等信息3.分析下具体操作的变化3.1分析commit和push操作下图展示commit和push命令操作情况
上方三个方框对应的图解情况,
1>初始本地仓库中跟踪分支和远程跟踪分支中情况,可以看出远程仓库,跟踪分支,远程跟踪分支的指针都指向c2
2>commit操作之后,跟踪分支的指针指向了一个新的版本c3
3>push操作之后,远程仓库和远程跟踪分支的指针也指向了c3
3.1分析fetch和merge操作1>远程仓库指向c4,本地仓库的跟踪分支和远程跟踪分支都指向c3
2>fetch操作之后,本地仓库的远程跟踪分支的指针指向了c4,但是此时跟踪分支没有变化,仍然指向c3
3>在进行merge origin/master操作之后,本地仓库的跟踪分支也指向了c4
4>这里要提下上面两部的合成操作,pull=fetch+merge,此操作会直接将本地仓库的跟踪分支和远程跟踪分支更新到最新版本c4
4.分析产生冲突和解决冲突的方法平时我会用小乌龟工具来操作git
当使用pull操作后,产生冲突
1>此操作产生的结果和fetch操作的结果相同,本地仓库的远程跟踪分支被更新到最新,本地仓库的跟踪分支没有变化
 
2>使用小乌龟解决冲突的方法
2.1>方法1:右键进入冲突编辑页面,
方法2:commit,commit后会出现文件列表,那个红色的文件就是冲突文件,双击进入即可
2.2>编辑解决冲突,下面左侧远程仓库版本,右侧是自己的版本,下侧是解决之后的版本.
2.3>标记为解决.
方法1,当解决了冲突之后,直接点击上方图片中的工具栏中的mark as resolved
方法2,右键resolve
2.4>创建一个新的版本号,并且commit
2.5>push操作,推送至远程仓库
5.reset和revert图解reset和revert操作1>reset之前的情况
reset之后的情况
 
2>revert之前的情况
revert之后的情况
reset方法的分析git reset HEAD~2
注意后面~带着1和2意思是倒退一个或者两个版本,如果不写则就是最新的,不变
除了在当前分支上操作，你还可以通过传入这些标记来修改你的缓存区或工作目录：
--soft – 缓存区和工作目录都不会被改变
--mixed – 默认选项。缓存区和你指定的提交同步，但工作目录不受影响
--hard – 缓存区和工作目录都同步到你指定的提交
 
通过记录.git文件夹中,版本号的变化情况,来分析
版本号最初状态版本号036aaa...85708
使用上面的命令 git reset HEAD~2
 
发现本地的版本会回退,注意上方红色的方块,表示回退了,远程跟踪分支上不会变,同时工作目录上的testGit4不会丢失,变成unknown状态了,如下
revert方法的分析用命令git revert HEAD^ (注意这里是^不是上面的~号了)
以前的版本记录情况
进行commit的情况
push之后的情况,发现是在处理上次冲突之后后退到了234这个地方,并且新创建了一个revert234
 
所以revert的回退是新产生了一次commit号
而reset操作是直接回退到某个版本,中间的版本号都会消除掉
 
 