可是你的老师是一个极其较真的人#xff0c;发现你俩写的学习计划太水And

forever

想象一下现如今你的老师同时叫你和张三各自写一份下半年的学习计划交给他。

可是你的老师是一个极其较真的人发现你俩写的学习计划太水了根本没上心因此将你俩的计划又打发回去给你们了叫你们再重写一份。

老师一看你这俩人第二次写的比第一次还烂赶快拿回去重写。

于是乎你俩的计划又被打了回去。

此时你暗自窃喜因为你做了第一次更改的备份那么直接把plan1发给老师任务即可完成了。

可是到了张三这里就让他叫苦连连经过多次在原计划上的修改早就忘了第一次的计划是什么版本了。

所以上述的你其实就在做版本管理。

为了方便”版本回溯我们只得不停地在做复制拷贝产出的⽂件就越来越多可是⽂件多不是问题问题是:

“随着版本数量的不断增多你还记得这些版本各⾃都是修改了什么吗?”

版本控制器。

所谓的版本控制器就是能让你了解到⼀个⽂件的历史以及它的发展过程的系统。

⽬前最主流的版本控制器就是Git。

Git可以控制电脑上所有格式的⽂件例如doc、excel、dwg、dgn、rvt等等。

对于我们开发⼈员来说Git最重要的就是可以帮助我们管理软件开发项⽬中的源代码⽂件

——前言

init此时我们就会发现在该路径下多了一个隐藏文件.git,.git目录是Git用来跟踪管理仓库的因此万不可手动修改里面的内容导致Git仓库无法管理。

当然.git文件里都有些什么呢在之后会细讲。

配置Git身份:

当安装Git后⾸先要做的事情是设置你的⽤⼾名称和e-mail地址这是⾮常重要的。

配指命令:

是⼀个可选项如果使⽤了该选项表⽰这台机器上所有的Git仓库都会使⽤这个配置。

如果你希望在不同仓库中使⽤不同的

name

上述演示的是配置到本地仓库中的例子。

我们可以通过以下命令查看当前Git配置的用户信息。

命令作用

我们全局配置的信息会存放在/home/xxx/.gitconfig里

(2)

后我们会发现当前的。

右侧为版本库在.git文件下。

Git的版本库⾥存了很多东西其中最重要的就是暂存区(因为这是一个新的Git仓库没有任何历史信息所以不存在暂存区)。

在创建Git仓库时Git会为我们默认创建一个唯一的master分支以及指向master的一个指针HEAD。

(关于什么是分支之后会细讲)。

“git

commit”时master分⽀会做相应的更新可以简单理解为暂存区的⽬录

由上述例子我们得知:新建或粘贴进⽬录的⽂件并不能称之为向仓库中新增⽂件⽽只是在⼯作区新增了⽂件。

必须要通过使⽤git

add和git

在之前我们已经添加了Readme文件了现在我们再继续在工作区创建几个文件一并进行添加到暂存区。

添加⼀个或多个⽂件到暂存区

携带-m,类似于一种备注。

这一步是由用户自己完成这部分内容绝对不能省略,并要好好描述是⽤来记录你的提交细节是给我们⼈看的。

我们可以看到自己所添加的文件通通被add到暂存区中然后⼀次性commit暂存区的所有修改。

Git管理日志查看:

截止目前位置我们成功将本地代码提交到了本地仓库并且能被Git管理起来。

也许你会说诶你说的都不对啊我咋没看到提交的地方在哪里呢?。

我们可以使用日志命令查看历史的提交记录:

显⽰从最近到最远的提交⽇志并且可以看到我们commit时的⽇志消息

git

需要说明的是4c35dfd627241ff...、“a1806786780b1e0...”这样的很长的字符串是每次我们进行“git

id(版本号)。

(当然这是它们内部计算生成出来的数字自然不是本篇的探讨范畴)。

再谈.git文件:

objects为Git的对象库⾥⾯包含了创建的各种版本库对象及内容。

当执⾏git

add命令时暂存区的⽬录树被更新同时⼯作区修改或新增的⽂件内容被写⼊到对象库中的⼀个新的对象中。

我们通过tree命令查看

objects时它将commit

15a37e9ef171cca4a5d985fccd1fcf9414b2c7cf,我们使用同样的方法打开并且继续分别打开ReadM和file1。

小结一下:

objects:包含了创建的各种版本库对象及内容可以简单理解为放了git维护的所有修改。

(4)

Git⽐其他版本控制系统设计得优秀因为Git跟踪并管理的是修改⽽⾮⽂件。

如何理解修改呢你在一个文件内新增一行“减少一行”“更改了某个字符”……

现在我们对ReadMe文件进行修改:

那么此时咱们工作区中的ReadMe文件和仓库中的ReadMe文件一定是不同的。

我们怎么知道呢因为这是我自己修改的更改的那么我肯定知道。

但是你总不能保证哪一天一个懵懂的二五仔跑来你的本地仓库中更改了某个文件而你不知道。

git

status命令⽤于查看在你上次提交之后是否有对⽂件进⾏再次修改。

git

status查到了自己的哪个文件被动过了可是动的哪里增加了那里删除了哪里你是一概不知的。

也许你维护着一个文件几行代码唔凭借你超强的记忆力能够分析出现如今的内容哪些地方给动过了。

然而如果是一分上百行上千行的代码呢如果你发现不仅仅一个文件通过

git

status查到被修改过了呢很显然你压根只能摇摇头双手一摊爱莫能助……

git

知道了对ReadMe做了什么修改后再把它提交到本地仓库就放⼼多了。

(5)

不知道你是否还记得前言的例子那则小故事说明了版本管理的重要性。

Git能够管理⽂件的历史版本这也是版本控制器重要的能⼒。

如果哪天你发现需要回退到某个历史版本,重新来过这个时候就需要版本回退的功能了。

值得注意的是回退的本质其实只是着眼于将版本库中的文件内容进行回退至于工作区或者暂存区是否也能进行回退那取决于命令参数。

git

参数作用--mixed为默认选项使⽤时可以不⽤带该参数。

该参数将

⽂件保持不变。

--soft参数对于⼯作区和暂存区的内容都不变只是将版本库回退到某个指定版本。

--hard参数将

暂存区

都退回到指定版本。

切记⼯作区有未提交的代码时不要⽤这个命令因为⼯作区会回滚你没有提交的代码就再也找不回了所以使⽤该参数前⼀定要慎重。

HEAD

HEAD表⽰当前版本

我想以这样的形式你一定难以理解这个版本究竟是怎样进行回退的这些参数是怎样运作的。

所以为了方便测试回退功能我们先做⼀些准备⼯作:

现如今我们发现版本3有问题想回到版本2想基于版本2重新进行代码编写。

由于我们这里是想要让工作区的ReadMe文件回到版本2因此携带的参数必须是

版本回退之后我们再次使用git

但此时我又发现版本3毕竟花费了我几十秒钟的心血现在我又想把版本回退到3上去。

但此时用git

id已经弄丢了。

(不过在我们这一台机器上其实在回退之前是记录到了版本3的commit

id的按照回退版本2的方式也就可以回退到版本3了)。

为此Git还提供了一个命令用于补救这种情况。

git

id但是是它的一部分而已。

是的Git在版本回退的时候也可以使用部分commit

事实上reflog并不是任何场景都下都能找到你丢失的commit

id如果开发时间够长导致commit

我想到了现在恐怕你对Git中版本回退的操作有了一定的理解。

这个图能很到位地解释各个参数的功能以及回退后的内容是什么。

如何理解版本回退

当然上面费那么多口舌是针对Git如何进行版本回退。

那么Git的内部是如何实现版本你回退的呢

因为Git在内部有个指向当前分⽀(这里就指master)的HEAD指针

refs/heads/master

现在我们正在工作区在长时间高压下把代码写得越来越烂想恢复到上一个版本。

这时候我们该怎么做呢

情况一:

唔这显然只能针对你几天只敲了那可怜的几行代码如果你连续干了三天写了上千行代码呢你怎么知道该删哪些保留哪些噢

git

diff命令用来查看不同版本的文件内容的差异嘛emm这个好。

于是乎你盯着那个

git

的输出在那里仔细比对啊仔细删啊可不能删除问题啊毕竟改完代码后反而多出来个bug又是一个费时间的活路……

git

当我们把工作区的文件”add”后还是保存到了暂存区呢怎么撤销呢

让我们来回忆一下git

reset的其中一个参数--mixed,可以将暂存区的内容退回到指定版本的内容并且保证工作区的内容不变。

所以接下来我们只需要让暂存区的内容回退即可。

此时我们就会发现现在的暂存区的干净的只是工作区需要修改。

还记得工作区如何进行撤销修改吗

情况三:

emm这时候你还是老大老实地按照版本回退的方式吧。

可是我怎么知道它的上一个版本呢这不用怕每一个objects对象内都会有一个parent指针指向该版本的上一个版本是谁。

git

--hard的唯一条件前提是你还没有将你本地仓库的代码推送到远端仓库(也就是git三板斧的最后一步

git

在Git中删除也是⼀个修改操作,在这里我们删除一个已经commit了的文件。

status

此时⼯作区和版本库就不⼀致了要删⽂件⽬前除了要删⼯作区的⽂件还要清除版本库的⽂件这样才能保证一致性。

git

因为这样做只是删除了工作区的部分还需要将该文件从暂存区、版本库中移除并且

三、分支管理

此时你会发现同样是三个月的准备时间你同另外一个也想参与这场大赛的张三一样做着相同的准备工作。

由此在正式参与该大赛之前你可以习得比张三多出来的一个技能增加赢得比赛的可能性。

我们在回到版本回退那里因为每一次Git提交就会保存每一次操作的comit

id方便回退查找。

于是乎这条由Git管理的时间线上会出现多个版本目录。

截止目前为止没有出现创建其他分支的情况所以这一条时间线里在Git里这一条分支叫主分支即master分支。

所以HEAD指针压根不是指向的提交的最新版本而是指向的当前分支,当前分支也就是master而真正指向最新一次提交的才是master。

每次提交master分⽀都会向前移动⼀步这样随着你不断提交master分⽀的线也越来越⻓,⽽HEAD只要⼀直指向master分⽀即可指向当前分⽀。

(2)

中新增一个指针dev“*”表示当前正在使用的分支也就是HEAD指向的分支(master)。

另外我们查看dev分支结构时发现dev

创建分支不是让它来走秀场的我们应该如何使用分支在分支环境下进行开发呢

切换分支

我们现在回退到master分支上再来查看Readme文件我们会发现之前更新修改的ReadMe文件还是原先的样子可是dev上的ReadMe文件已经是被修改了的。

那么能给出解释的唯一理由就是现在这两个ReadMe文件一定不是同一个对象

看到这⾥就能明⽩了因为我们是在dev分⽀上提交的⽽master分⽀此刻的提交点并没有变此时的状态如图如下所⽰。

当切换到master分⽀之时HEAD就指向了master当然看不到提交了

(4)

紧跟上一个问题现如今我的master分支看不到dev提交的新版本而我们需要做的就是将“dev”分支合并到“master”分支上。

命令⽤于合并指定分⽀到当前分⽀

Fast-forward代表“快进模式”也就是直接把master指向dev的当前提交所以合并速度⾮常快。

当然也不是每次合并都能Fast-forward。

(5)

在分支和主分支合并完成后对我们来说dev分支其实就没啥用了。

那么dev分支就应该没删除掉。

删除分支

因为创建、合并和删除分⽀⾮常快所以Git⿎励你使⽤分⽀完成某个任务合并后再删掉分⽀这和直接在master分⽀上⼯作效果是⼀样的但过程更安全。

(6)

有时候并不是你想合并就能合并成功的有时候可能会遇到代码冲突的问题。

我们现在先创建并切换到新分支dev1上去。

dev1

之后我们切换到master分支上很显然我知道该ReadMe文件仍然是不会受到dev1修改的影响的。

并且我们会在master分支上对ReadMe文件进行修改,并进行提交。

master

这种情况下Git只能试图把各⾃的修改合并起来但这种合并就可能会有冲突:

当文件发生冲突时查看⽂件内容时Git会⽤来标记出不同分⽀的冲突内容,内容如下:

此时我们必须要⼿动调整冲突代码并需要再次提交修正后的结果(再次提交很重要切勿忘记)。

当然这里的手动删除是保留两个版本commit的其中一个。

到这⾥冲突就解决完成此时的状态变成了。

git

模式下删除分⽀后查看分⽀历史时会丢掉分⽀信息看不出来最新提交到底是merge进来的还是正常提交的。

但在合并冲突部分我们也看到通过解决冲突问题会再进⾏⼀次新的提交得到的最终状态为:

Fast

所以在合并分⽀时加上”--no-ff“”参数就可以⽤普通模式合并合并后的历史有分⽀能看出来曾经做过合并⽽

fast

⾸先master分⽀应该是⾮常稳定的也就是仅⽤来发布新版本平时不能在上⾯⼲活

那在哪⼲活呢⼲活都在dev分⽀上也就是说dev分⽀是不稳定的到某个时候再把dev分⽀合并到master上。

(8)

假设目前你正处于dev2分支上进行开发开发到一半时突然发现master分支上存在严重的bug需要被解决。

在Git中每个bug都可以通过⼀个

场景一:

可以将当前的⼯作区信息进⾏储藏,被储藏的内容可以在将来某个时间恢复出来

git

stash”命令可以将当前的⼯作区信息进⾏储藏被储藏的内容可以在将来某个时间恢复出来。

因为bug出现在master分支上所以我们得切换回master分支上新建立修复bug的分支。

把fix_bug分支上修复的代码合并到master分支,最后并删除fix_bug分支

dev2

⼯作现场还在Git把stash内容存在某个地⽅了但是需要恢复⼀下如何恢复现场呢我们可以使⽤

git

不过呢我们也可以看到在dev2查看ReadMe文件时是看不到修复好bug的新文件是什么此时的状态图该为:

Master

中当然看不⻅修复bug的相关代码。

而我们最终的目的是让master分支合并到dev2分支上去于是乎正常情况下我们现在是会切回

master

但这样其实是有⼀定⻛险的因为在合并分⽀时可能会有冲突⽽代码冲突需要我们⼿动解决(手动解决)。

可是现在解决代码冲突的问题是回到了master分支上并且我们无法保证一次性就能解决掉冲突内容面对实际中的几百行、甚至几千行代码时解决的过程中难免⼿误出错导致错误的代码被合并到

⼀个好的建议就是:在⾃⼰的分⽀上合并下master,再让master去合并dev。

这样做的⽬的是有冲突可以在本地分⽀解决并进⾏测试⽽不影响master。

删除临时分支:

添加⼀个新功能时你肯定不希望因为⼀些实验性质的代码把主分⽀搞乱了所以每添加⼀个新功能最好新建⼀个分⽀我们可以将其称之为feature分⽀在上⾯开发完成后合并最后删除该feature分⽀

但天有不测风云常在河边走哪有不湿鞋的。

你亲爱的产品经理告诉你某个已经开发到一半的feature分支功能叫停了虽然你的辛苦白费了但是这个

git

所以分支到底有什么用呢假设你准备开发⼀个新功能但是你还没有完全开发完成如果⽴刻提交由于代码还没写完不完整的代码库会导致别⼈不能⼲活了。

如果等代码全部写完再⼀次提交⼜存在丢失每天进度的巨⼤⻛险。

现在有了分⽀就不⽤怕了。

你创建了⼀个属于你⾃⼰的分⽀别⼈看不到还继续在原来的分⽀上正常⼯作⽽你在⾃⼰的分⽀上⼲活想提交就提交直到开发完毕后再⼀次性合并到原来的分⽀上这样既安全⼜不影响别⼈⼯作。

并且Git提供高效的分支创建、切换和删除帮助我们提高开发效率。

祝你好运向阳而生~