1.先画个图,先对git的操作有个直观了解
2.分析下git中文件是怎么存储的
正如下面所示git存储不是每次更改就会产生一个新的文件,而是产生一个版本,这个版本对应着记录每个文件的不同情况
实际上在我们的项目中的.git/objects文件夹，有很多文件夹,他们使用 sha-1 的前两位创建了文件夹，剩下的38位为文件名。我们先称呼这些文件为 obj 文件
3.分析具体操作的变化
3.1分析commit和push操作
下图展示commit和push命令操作情况,注意看(HEAD,master)指针的变化情况
下面具体分别分析上图三个方框中的情况
1>初始本地仓库中跟踪分支和远程跟踪分支中情况,可以看出远程仓库,跟踪分支,远程跟踪分支的指针都指向c2
2>commit操作之后,跟踪分支的指针指向了一个新的版本c3
3>push操作之后,远程仓库和远程跟踪分支的指针也指向了c3
3.2分析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:右键进入冲突编辑页面, 具体操作是右键空白点击->tortoiseGit->Edit conflicts,然后进入编辑页面
方法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方法的分析
- --soft – 缓存区和工作目录都不会被改变
- --mixed – 默认选项。缓存区和你指定的提交同步，但工作目录不受影响
- --hard – 缓存区和工作目录都同步到你指定的提交
发现本地的版本会回退,注意上方红色的方块,表示回退了,远程跟踪分支上不会变,同时工作目录上的testGit4不会丢失,变成unknown状态了,如下
revert方法的分析
用命令git revert HEAD^ (注意这里是^不是上面的~号了)
以前的版本记录情况
进行commit的情况
push之后的情况,发现是在处理上次冲突之后后退到了234这个地方,并且新创建了一个revert234
综合以上分析
revert的回退是新产生了一次commit号
而reset操作是直接回退到某个版本,中间的版本号都会消除掉