GIT[基本概念]

GIT

摘自:https://zhuanlan.zhihu.com/p/263050507(筛选)

Git是世界上先进的**「分布式的版本控制系统」,而SVN「集中式的版本控制系统」**,SVN对于版本的管理集中于中央服务器中,而Git对于版本的管理可以在本地。

在Git中有四个概念:「远程仓库、工作区、暂存区、版本库」。远程仓库就是我们Git的服务器,用于存储已经管理团队的代码。

工作区、暂存区、版本库是我们本地的,例如当我们初始化git init后,就会在当前的目录下出现.git目录,「redis目录就是我们的工作区,而.git目录是我们的版本库所有的版本信息都在这里」

img

在.git目录下index文件(.git/index),这就是**「暂存区」,叫做stage或者index,index和我们的数据库的index类似,所以我们有时候也叫它为「索引」**。

这四个区域实现的原理图所下所示,使用过Git的对于下面的命令再熟悉不过了。

img

从原理图中可以看出代码可以再不同的level之间转移,也可以跨level之间转移,所有的这些动作都是通过Git的命令去实现。

初始化的时候Git还会自动为我们创建第一个分支master,以及指向master的一个指针叫做HEAD

img

克隆项目

在我们实际的工作环境中,都会从服务器上进行克隆项目到本地,Git中使用git clone命令可以进行克隆项目:

git clone https://github.com/liduchang/redis

执行git clone就会生成一份副本,在本地仓库和工作区都会同步副本,具体的原理图如下所示:

img

提交代码

从上面的图中我们可以到,代码可以在不同level之间移动,高level到低level,或者逆向低level到高level,也可以跨level之间移动。

Git中代码从低level到高leve的移动主要依靠以下命令:

  • git add .:文件添加进暂存区。
  • git commit -m "提交信息":文件添加进本地仓库,-m参数改为-am可以直接推向本地仓库。
  • git push:文件推向远程仓库。

img

运行git commit -a相当于运行git add把所有文件加入暂存区,然后再运行git commit把文件提交本地仓库。

代码回退

那么从高level向低level移动代码的命令如下:

  • git pull:从远程仓库拉取代码到本地。
  • git reset --files:用本地仓库覆盖暂存区中修改,也就是覆盖最后一次git add的内容。
  • git checkout --files:把文件从暂存区复制到工作区,用于放弃本地的修改。
  • git checkout HEAD --files:回退最后一次的提交内容。

img

代码冲突

在团队中集体使用Git的时候,每个人都提交自己的代码最后合并到主干,总有会push失败的时候,因为push的本质:「就是用你本地仓库的commit记录去覆盖远程仓库的commit记录」

但是别人提交了一些代码,而你本地并没有这些代码,这样代码就会被覆盖,导致别人的commit的记录就不存在,这个是绝对不允许的。

所以,每次push的时候Git就会检查,若是存在这种情况就是push失败,只要先git pull一下,将本地仓库与远程仓库先合并一下,最后push就可以成功了,若是文件中已经存在在冲突代码,只要打开文件重新解决一下冲突即可。

分支管理

Git中比较最重要的一点就是分支的概念,有了分支就有了合并和衍合的操作,「合并」「衍合」能够「有效的对代码版本的管理」

Git的初始化中有一条默认的主分支叫做master,每一次的提交都会串成一条时间线,这就是一条分支,当前分支由HEAD指针指向:

动图封面

当每次发生代码提交的时候,当前指向就会向前形成一个新的版本,假如再创建一个新的分支bran,并且当前的提交指向新的分支,这样新的分支随着时间的推移就会形成许多版本:

img

当新分支开发完后,提交仓库,并合并到主干master,最后删除bran分支,这样就完成了一次个人的开发:

img

所以,假如主分支上只建立一条分支的话,分支的合并是非常快速的,只需要移动master分支到当前提交,然后将HEAD指针指向master,最后删除bran分支就完成了。

但是,事实上并不是这样的,在一个多人协作的开发团队中,往往每个人都会建立自己的分支,有自己的提交,最后合并到主干,当自己提交的时候,远程仓库代码就会存在自己本地仓库并未有的代码,这样就会导致push失败。

例如:程序员Tom和Jerry同时迁出代码,他们的初始代码分支都如下图所示:

img

当Tom开发自己的业务模块,提交代码并且合并到主干后,远程主干分支如下图所示:

img

「远程仓库master已经不再指向gs234,而是新生成了一个版本dfd453,作为当前指向的版本」

与此同时,Jerry的本地也同时开发完自己的模块后,分支如下图所示:

img

在Jerry的本地环境中,他的**「本地仓库master还是指向gs234」**,Jerry在自己新建立的一个分支bran中进行开发,开发完后合并分支,最后master就会指向ed489

当Jerry再次提交代码,Git就会检查远程仓库与Jerry的本地仓库,进行对比后,发现远程仓库存在Jerry的本地仓库不存在的代码,就需要Jerry将远程仓库执行git pull后,自行解决冲突。

上面说了分支基本原理,已经管理分支出现的问题,下面我们就来一步一步的深入操作分支的基本命令。

新建分支

Git新建一个分支的命令为:git branch <分支名字>,新建立后分之后,切换分支的命令为:git checkout <分支名字>

新建分支的实质:「就是新建立一个引用,指向当前提交,master就好比一个引用」;切换分支的实质:就是将HEAD由指向原来的引用,重新指向要切换的分支的引用上:

img

当然上面创建分支并且合并分支的两条命令可以合并成一条命令:git checkout -b <分支名字>

当切换分之后,每次commit提交代码时HEAD指针就会跟随着新的bran分支移动,形成bran分支上的每一个版本:

img

假如,在新的bran分支上开发到某一个版本,再次切换回master分支进行开发就会形成分叉:

img

查看分支

当分支创建好了,你可以通过:git branch,来查看自己本地的分支情况:

img

分支前面带有*号的表示当前的分支,查看分之后,你就可以很清楚的知道自己要checkout哪条分支了。

合并分支

开发玩自己模块后,后面就会在自己本地进行合并分支,合并分支的命令:git merge <分支名字>,它表示**「合并指定的分支到当前分支」**,比如:当前分支为master,执行:git merge bran,表示合并bran分支到当前master分支上。

分支合并也会有失败的情况,当你的两条分支都修改的相同的文件,这时候Git就无法判断你要保留哪一个修改,就会出现merge冲突。

例如:我先在master分支修改README.md文件,然后提交本地仓库:

img

然后切换回分支dev,再次修改README.md文件,再次提交

img

最后进行合并分支,此时在你两次修改的README.md文件中就会出现两次修改的冲突代码:

img

因为你两次修改同一文件的操作,合并后Git并不知道你要保留哪一次的操作,所以它就会将这个决定交给你自己决定,它只告诉你文件中哪里的代码冲突了,具体怎么改就由你自己去弄。

img

删除分支

最后是删除自己新建的分支,通过:git branch -d <分支名字>,进行删除分支,假如分支删除不了,可以通过:git branch -D <分支名字>,强制删除分支:

img

Git中删除分支的实质:dev只是一个分支的引用,所以删除分支也就是删除这个引用,并不会删除任何conmit,所以删除操作也是非常高效的。

假如一条分支commit的引用被删除,那么这条分支的就没有任何引用指向,这样就会找不到这条分支,最后就会被Git回收机制回收。

查看远程

在多人协作的团队下,你可能要随时查看远程仓库的情况,可以通过:git remote,进行查看,加上-v参数可以查看远程仓库的详细情况。

git remote
git remote -v

推送分支

img

分支的推送到远程上一节已经提过,使用git push命令就可以进行分支的推送,命令后面加上分支的命令,表示具体推送哪条分支:

git push origin master // 将本地master分支推送到远程库

拉取分支

分支的拉取使用git pull命令,这条命令相当于以下两条命令:

git fetch
git merge

但是一般实际工作中,都可能会直接使用git pull命令:

img

分支管理策略

在合并分支的时候,Git会以快速合并的模式进行合并(Fast forward),但是这种模式删除分支后,会丢失分支的信息。

Git中还可以以**「普通模式」**进行合并,在原来git merge命令后面加上–no-ff参数即可,合并的命令如下:

$ git merge --no-ff -m "message" dev

临时存取工作区的改动

在开发中,若是某一时刻你想把当前的改动临时进行存放起来,可以使用git stash命令,它表示将改动的文件存储到一个独立的存储区域,并不会被提交,当再次需要的时候可以随时取出来。

这里要注意的是:「git stash的是改动的文件,也就是被Git追踪的文件,新添加的文件并没有被Git追踪,所以git stash并不会stash」

img

git stash命令也可以加上save命令后面再加上备注信息,方便查看:

git stash save "备注信息"

git stash成功后**「本地的工作目录的代码会和本地仓库一样」**,git stash后可以通过git stash list命令查看之前stash的历史记录,当再次需要将改动的文件取出来时候,可以通过以下命令:

git stash pop

git stash pop表示**「弹出第一个被stash的记录,并且该stash会从历史记录中删除」;也可以使用git stash apply命令「弹出stash,但是这条命令stash任然会保存在stash历史记录中」**,你也可以通过:git stash drop命令来删除。

img

这一篇就只讲解了Git的分支原理以及Git的临时存取操作,限于篇幅,我们今天就到这里,我们下一期继续图解Git操作,我们下一期再见。

这一篇我们继续图解Git,上两篇原创图解了Git的基本操作,有兴趣的可以看一看[]和[]。

这一篇写完基本Git的操作就图解完了,如果想深入了解Git,这里可以推荐一些Git的硬核书籍:【精通Git】、【GitHub入门与实践】、【Git权威指南】、【Git版本控制管理】、【GitHub实践】。

…(img-mUC6O40i-1684305577842)]

这一篇就只讲解了Git的分支原理以及Git的临时存取操作,限于篇幅,我们今天就到这里,我们下一期继续图解Git操作,我们下一期再见。

这一篇我们继续图解Git,上两篇原创图解了Git的基本操作,有兴趣的可以看一看[]和[]。

这一篇写完基本Git的操作就图解完了,如果想深入了解Git,这里可以推荐一些Git的硬核书籍:【精通Git】、【GitHub入门与实践】、【Git权威指南】、【Git版本控制管理】、【GitHub实践】。

这些都是一些关于Git的比较好的书籍,有兴趣的可以可看一看,网上也有很多电子书。闲话不多说,下面就开始我们的正题。

猜你喜欢

转载自blog.csdn.net/weixin_43925768/article/details/130725541