三、git总结

2019-03-30  本文已影响0人  lifeline张

1、git init 初始化一个git仓库,即把这个文件夹下面所有的文件纳入到版本控制之中
2、添加一个read.TXT文件,内容如下:


Git is a version control system.
Git is free software.


3、git add read.TXT 可以反复使用,添加多个文件
4、git commit -m "wrote a readme file" 可以一次提交多个文件
修改文件如下:


Git is a distributed version control system.
Git is free software distributed.


4、git status 查看状态,下图是我修改文件,但是没有使用add命令的时候,调用该命令出现的结果

image.png
5、git diff readme.TXT查看差异,在4的基础上,没有进行add,此时查看不同结果如下:
image.png
6、执行完git add命令之后,再查看状态如下:
image.png
执行git diff命令结果如下:
image.png
可以得出结论:git status是查看工作区是否有被修改的文件以及被修改文件被提交到哪一步了,而git diff是用来比较工作区与暂存区的文件的差异
调用完git commit之后,再调用git status,结果如下:
image.png
可以看到此时工作区没有修改的文件了,也就是工作区跟版本库保持一致了。
7、修改readme文件如下:

Git is a distributed version control system.
Git is free software distributed under the GPL.


8、git add
9、git commit -m "append GPL"
10、

image.png
11、git log查看提交历史
image.png
当使用git log --pretty=oneline的时候,结果如下:
image.png

在第一张图中的commit后面(也就是标黄的那部分)的是commit id,是git计算的一个数,用来区别每次操作
12、版本回退
在git中,用HEAD表示当前版本,也就是最新的提交,上一个版本就是HEAD,上上一个版本就是HEAD,当然往上100个版本写100个比较容易数不过来,所以写成HEAD~100。
git reset --hard HEAD^,结果如下:

image.png
可以看到,现在版本回退到上一个版本了。
此时查看文件内容:
image.png
可见,内容确实回退到上一个版本了。

但是此时调用git log的时候,结果如下:

image.png
最后的那次提交不见了,只剩下了两次,此时如果想要到那个版本,该怎么办?
如果此时你没有关掉命令行窗口,则可以往上翻到最后一次提交,找到那次提交的commit id,然后调用命令git reset --hard 58b58,结果如下:
image.png
查看文件内容:
image.png
确实回来了。

如果关掉了命令行窗口,该怎么办?因为之前已经到最后的版本了,所以这里先进行一次版本回退操作,到 add distributed版本。

image.png
此时使用git reflog命令查看命令历史,结果如下:

可以看到我所有的提交以及版本回退操作,在这里就能找到最后一次提交的commit id了,然后进行版本回退即可:
image.png
13、工作区、暂存区与版本库

前面讲了我们把文件往Git版本库里添加的时候,是分两步执行的:

第一步是用git add把文件添加进去,实际上就是把文件修改添加到暂存区;

第二步是用git commit提交更改,实际上就是把暂存区的所有内容提交到当前分支。

因为我们创建Git版本库时,Git自动为我们创建了唯一一个master分支,所以,现在,git commit就是往master分支上提交更改。

你可以简单理解为,需要提交的文件修改通通放到暂存区,然后,一次性提交暂存区的所有修改。
14、接13
修改readme文件如下:


Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.


新增一个LICENSE文本文件(内容随便写)。


This is LICENSE file.


然后查看状态如下:

image.png
Git非常清楚地告诉我们,readme.txt被修改了,而LICENSE还从来没有被添加过,所以它的状态是Untracked。
调用两次add命令再查看状态如下:
image.png
下面这个图中stage中没有完全把目录结构写出来
image.png
提交之后如下:
image.png
这个版本控制有点厉害啊,应该是我操作的时候复制粘贴删除等,虽然内容一样,但是这都能整出来。。
15、针对暂存区再做一次测试:
现在版本库和工作区中的文件是:

Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.


修改文件如下:


Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
1


此时未执行add命令,调用git diff readme.TXT,结果如下:

image.png

再一次修改文件如下:


Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
2


结果如下:


image.png

因为暂存区中有完整的上一个版本的内容,所以git diff比较的就是工作区跟暂存区之间的差异。
此时调用git diff --cached readme.TXT,结果如下:

image.png
说明该命令是比较版本库与暂存区的差异。
此时调用git diff HEAD,结果如下:
image.png
跟git diff的结果完全一致,说明:确实是跟版本库做对比,查看当前工作区修改的内容。
16、接15
执行一次add命令,
修改readme文件如下:

Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
2
3


此时分别执行git diff和gitdiff head和git diff --cached readme.TXT,如下:


image.png
image.png
image.png

可以看到,git diff比较的是工作区与暂存区的差异,git diff head比较的是上一个版本与工作区的差异。
综上:git diff在没有add之前比较的是上一个版本跟当前工作区的差异,在add之后比较的是工作区与暂存区的差异;git diff HEAD 一直比较的是上一个版本跟当前工作区的差异,git diff caches比较的是暂存区与上一个版本的差异。
这样理解是错的,git diff一直比较的是工作区跟暂存区的差异,只是因为暂存区中有上一个版本而已,所以在没add之前,跟add之后会出现差异。
git diff 本身只显示尚未暂存的改动,而不是自上次提交以来所做的所有改动。尚未暂存的改动,用词真的是精辟

image.png
image.png

17、修改的撤销
首先将文件恢复至原始状态:


Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.


修改文件:


Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
1


image.png
此时没有add操作,调用git checkout -- readme.TXT命令之后,结果如下:
image.png
可以看到修改被撤销了。
然后再进行如下操作:
修改文件:

Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
1


add之后再修改文件:


Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
1
2


调用git checkout 命令结果如下:

image.png
说明git checkout -- readme.TXT命令是让这个文件回到最近一次git commit或git add时的状态。
这个时候文件已经进暂存区了,还没有提交,要想撤销暂存区的修改,可以使用git reset HEAD readme.TXT命令,结果如下:
image.png
此时调用git status和gitdiff结果如下:
image.png
可以看到文件恢复至未add的状态,此时再调用checkout命令,结果如下:
image.png
可以看到修改被完全撤销了。
如果已经commit了,则可以使用版本回退功能。

18、删除
执行rm命令,删除文件,如下所示:

image.png
这个时候,Git知道你删除了文件,因此,工作区和版本库就不一致了,git status命令会立刻告诉你哪些文件被删除了。现在你有两个选择,一是确实要从版本库中删除该文件,那就用命令git rm删掉,并且git commit。
image.png
另一种情况是删错了,因为版本库里还有呢,所以可以很轻松地把误删的文件恢复到最新版本:
image.png
image.png
此时文件就恢复了。
19、远程仓库
首先注册github'账号,因为这里是使用ssh加密,所以要先进行一些设置:
第1步:创建SSH Key。在用户主目录下,看看有没有.ssh目录,如果有,再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件,如果已经有了,可直接跳到下一步。如果没有,打开Shell(Windows下打开Git Bash),创建SSH Key:ssh-keygen -t rsa -C "431370446@qq.com",然后一路回车,使用默认值即可。如果一切顺利的话,可以在用户主目录里找到.ssh目录,里面有id_rsa和id_rsa.pub两个文件,这两个就是SSH Key的秘钥对,id_rsa是私钥,不能泄露出去,id_rsa.pub是公钥,可以放心地告诉任何人。
image.png
第2步:登陆GitHub,打开“Account settings”,“SSH Keys”页面:
然后,点“Add SSH Key”,填上任意Title,在Key文本框里粘贴id_rsa.pub文件的内容:
为什么GitHub需要SSH Key呢?因为GitHub需要识别出你推送的提交确实是你推送的,而不是别人冒充的,而Git支持SSH协议,所以,GitHub只要知道了你的公钥,就可以确认只有你自己才能推送。

当然,GitHub允许你添加多个Key。假定你有若干电脑,你一会儿在公司提交,一会儿在家里提交,只要把每台电脑的Key都添加到GitHub,就可以在每台电脑上往GitHub推送了。
第三步:具体推送

image.png
20、分支基础知识
版本回退里,你已经知道,每次提交,Git都把它们串成一条时间线,这条时间线就是一个分支。截止到目前,只有一条时间线,在Git里,这个分支叫主分支,即master分支。HEAD严格来说不是指向提交,而是指向mastermaster才是指向提交的,所以,HEAD指向的就是当前分支。
一开始的时候,master分支是一条线,Git用master指向最新的提交,再用HEAD指向master,就能确定当前分支,以及当前分支的提交点:
image.png
master其实是一个分支名而已,指向这个分支下的最新的版本,head指向当前分支。
image.png
image.png
21、分支测试
目前文件内容如下:

Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.


首先,创建dev分支:


image.png

查看分支:


image.png
此时修改文件为:

Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
1


在dev分支上进行提交:


image.png

切换回master分支查看文件:


image.png
因为那个提交是在dev分支上,而master分支此刻的提交点并没有变。
合并分支之后再查看:
image.png
image.png
image.png

22、解决冲突
首先先建立一个分支然后feature1然后再回到master分支,则会提示比远程多一次提交:



然后转到feature1分支上,在该分支上修改文件如下:


Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
1
featrue1


然后提交,再转到master分支上:
修改文件如下,然后提交:


Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
1
master


image.png

这种情况下,Git无法执行“快速合并”,只能试图把各自的修改合并起来,但这种合并就可能会有冲突,我们试试看:


image.png

这时候再去看工作区的readme文件会发现:变成了这个样子:


image.png
我们修改为以下,然后保存提交:

Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
1
master
featrue1


image.png
image.png

可以查看合并冲突的记录:


image.png

最后删除分支:


image.png
23、分支管理策略
通常,合并分支时,如果可能,Git会用Fast forward模式,但这种模式下,删除分支后,会丢掉分支信息。

如果要强制禁用Fast forward模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息。
测试:
在dev分支上岸原来的模式提交,在dev3上不用Fast forward模式模式提交:

image.png
image.png
可以看到保留了dev3的分支历史。
image.png
24、bug分支
image.png
首先在dev3分支干活,但是做的修改没add,这时候调用git stash来保修现场,然后转到maste分支,生成dev4分支,在该分支上干完活病提交之后,在返回dev3分支,调用git stash apply来恢复现场
image.png
image.png
25、远程推送
image.png
image.png image.png
image.png
上一篇下一篇

猜你喜欢

热点阅读