00:00
这节课说一下。To分支和墨迹分支的运用实例。我们用简单的实例来讲解to分支和墨迹分支的操作方法。例如在开发功能的淘派分支图中啊,需要修改一个bug,这时墨迹分支还是处于开发功能之前的状态,在这里新建修改错误用的主题分支。就可以从开发功能的这个作业独立出来,以便开始新的一个工作。完成bug修正的工作之后,把分支导入原本的这个墨迹分支。就可以去公开发布了,再回到原来的这个O分支,继续进行开发的一个操作。但是我们再回到这个O分之的时候,继续进行操作的时候,你会发现你需要之前修改的这个。啊X这个bug的这个内容,修改bug这个内容有两种方法可以。嗯,把X修改的内容导入到O这个分支,一种是直接墨迹,另一种就是。
01:06
使用这个B导入提交X的一个分支。这里我们使用这个B合并分支的一个方法。直接在当前所在的O分之上使用。把。模的分支。修改后bug的最新的提交使用给。啊,同步过来给合并过来,这时候就可以继续开发一个新的功能了。这样有效的利用分支的话,可以同时进行不同的作业了,下面我们来操作一下。首先进入到我们的。本地的一个版本库。本地的数据库。然后看一下当前所在的是ma的分支,我们以must的分支。创建一个O分之checkout-B创建O分之。
02:05
并且。切换到欧分值。当前是在这个欧分之看一下当前的一个历史记录,是有这四个历史记录。好。现在我们还没有进行,嗯,在O上面还没有进行开发。但是这时候啊,在master分支可能出现了bug,我们要紧急去修复bug。此时回到ma的分值。以must的分支为基础。切换一个,呃,八个分之X。杠B切,创建并切换X分值,现在我们就在这个X分值,我们在X分值里面去修改我们的bug,打开我们的文件。写上我们。
03:00
Bug修改的内容保存。之后看一下X分之的状态。有一个更改,添加到索引区,提交到版本库,提交到数据库。八这时候看一下历史记录。啊,我们的X分值就比较领先你其他的分值啊。因为我们提交了一下,修改了一个bug。此时大再回到must分支。然后合并X分之,对bug进行了一个修复。可以看到已经合并过来了,看一下日志。现在啊,Must和X就在一个分值好。此时bug已经修复,我们可以继续回到这个O分值去,嗯,进行我们的作业,Get。
04:08
CH。哦。啊,现在已经处于这个欧分之,但是我们欧分之呢,也需要这个X做的一个修改,因为它是修改了一个bug嘛,我们在O分之上可能也存在这个bug啊,我们怎么同步X这个修改呢?有两种方法,一种是使用墨迹。还有一种是。使用B同步max的就是合并max的一个修改,我们这里使用B。Getb must。可以看到啊,已经合并成功,现在我们来看一下欧的一个历史记录。现在我们的O已经把must的分支最新的一个历史的提交已经合并了过来,这时候我们就可以开始去进行我们的作业了。
05:05
接下来看一个成功的gate分支模型。也是我们在实际的项目开发中用的比较多的一个get分支。这块的。啊,一个范例。这个用例主要分为主分支、特性分支、release分支。Hot fixx文职。分别用四个种类的分支来进行开发。嗯,首先是这个图,这个是主分支。Hot fix文职。Release分支。Develop分支以及。Feature特性分支。主分支。有两种must分支和develop分支啊,有两种,一个是must的分支,一个是这个develop分支。MAS的分支只负责管理发布的状态,在提交的时候用标签记录发布的版本号。
06:05
也就是说,我们的master分支实际上是用来发布我们的项目。的一个分支,它的上面的内容一定是最稳定的一个版本。Develop分支是针对日常开发。啊,进行发布的一个分支,刚才已经讲过啊,有关合并分支的一个作用。特性分支,特性分支就是我们在前面讲过的topic分支的功能。这个分支主要是针对新功能的开发,在bug修正的时候从develop分支分叉出来的,基本上不需要共享特性分支的操作,所以不需要远端。控制。完成开发后,把分支合并回develop分支发布。Release分支release分支是为了release做准备的,通常会在分支前面名称加上release杠。
07:01
在release前,也就是我们的项目发布前,需要在release分支做最后的调整,而且为了下一版的release开发。用着develop分支的上游,一般开发是在develop分支上进行到了可以发布的状态时,在创建release分支,在release分支上为发布做最后的一个bug的修正。啊,到了可以发布的状态时,把这个release分支合并到master分支,并且在合并提交里添加啊release版本号的一个标签。要导入release分支的所做修改,同时也要合并回develop分支,我们的开发分支也需要这个release分支上做的一些调整。Hot fix分支hot fix分支,呃,一般是在发布产品的过程中啊,需要紧急修正,从master分支创建分支。通常会在这个分支名称前面加上hold face。例如在develop分支上开发还不完整时,但是我们已经发布的版本需要做紧急的修改,此时develop分支如果要创建一个新的版本,可能会需要花费很长的一个时间,所以最好选择从master的分支上直接创建分支,进行呃一个修改,最后再进行一个合并。
08:21
修改时创建的hold fix分支最终也要合回develop分支,我们假定是一个bug的话,Must分支如果存在这个bug,那么我们的develop开开发分支同样可能会存在这个bug,所以最后修改的这个hot fix分支也要和回develop分支以下。好,这些概念性的东西呢,让我们来看一下这个图,一般我们有两个主分支,一个pass的分支,是用来我们发布版本啊,发布正式的一个版本使用,还会有一个开发分支,是develop分支,这个一般我们是做开发和使用。在我们啊开发的这个过程中呢,可以从这个develop分值去分出去很多的一个特性分值,比如啊这个人去开发。
09:05
啊,登录功能,这个人去开发注册功能,最后他们开发完成之后,我们依次合并到开发的分支。好,一直到了这里,到了这里呢,我们认为我们项目可以,呃完成了,已经完成了大半部分,可以先发布了,这个时候我们不要直接发布出去啊,先发布到这个release版本,在release版本由测试人员进行测试,并且我们我们做最后的一个修正啊,修正完成之后。最后发现这个版本已经非常稳定,没有任何问题了,就可以。合并到MAS的分支,由MAS的分支打好标签,打好版本号,开始发布这个产品。啊,因为我们在release分支上做的这些调整可能是有益的啊,但是我们develop分值并没有这些调整,所以需要把在release分支上做的调整合到develop分支。这就是一个release分支,就是未发布前做准备,在release分上做最后的一个调整好。
10:05
最后啊,我们现在的项目版本是处于这个版本,但是这个这个项目的这个版本呢,有用户反馈出现了很严重的一个bug,这时候我们的develop分支可能还在开发其他的功能,不可能说停下来手头的工作,放弃手头的这个更改啊去修改的问题,此时最快的速度应该是从master分支切换出来一个啊hot fix分支进行bug的一个修复,修复完这个bug之后啊,合并到ma分支,并且再打一个版本号进行发布就可以了。因为啊,这个bug可能是不被察觉的啊,突然有一天就被测出来了,那么既然我们在master分支会有这个bug的一个问题,在我们的开发分支啊,肯定也会有这样一个bug的问题,所以在修改完这个bug之后,我们要在呃,D develop了分支,把后fix分支也进行合并一下。这就是一个比较标准的一个成功的一个get的分支模型,下面我们通过这个实例来操作一下。
11:14
首先看一下我们当前分支的一个情况啊,我们当前还是这些分支先回到主分支。然后。看一下分支列表。这些分支都没有用啊,我们把它都删掉吧。按上可以看到上一次数字的一个命令方向键的上键。现在我们把分值都删掉了,这是一个只剩下一个must的分值啊,这时候呢。
12:01
我们以must的分值啊为基础。创建并切换到develop分支。然后。Develop分支就作为我们的开发分支。啊,我们接着去为我们的团队成员去分配一些任务。从develop分支切出来一个。创建一个FN分值,让。一个人去开发FA的功能,接着在创建一个FB的一个分支,让一个人去开发FB的这个功能。现在来查看一下分支的一个状态,可以看到这是我们的啊,主分支,发布分支,这是我们的主分支,用于开发的div develop部分值,这两个是特性分支。
13:00
呃,用来啊,分别让不同的人去写不同的功能,当他们写完这个功能,比如我们现在切换到。A分之。去。写这个功能,FA的一个功能保存。写完之后。看一下状态,然后添加到索引区。提交到数据库。接着啊,我们去B分支FB分支去开发FB功能,我们现在是在模拟两个人去同时开发功能啊,现在已经在FB分值。编辑这个文件。写入FB。保存。添加到索引区,Get commit。
14:01
请加到数据库FB好。接下来。我们回到develop分值,分别合并FA和FB这两个分支,Get checkout develop合并FA。这个特性分支好,接着合并FB,在合并B的时候啊,会产生一个冲突,因为FA和FB这两个人同时修改了这个文件,看一下当前冲突的一个文件,Bos modify都修改了这个文件,对吧?Date也可以查看一个这个文件具体冲突的一个地方。现在我们来手动解决冲突。保存。手动解决充冲突之后重新提交。
15:01
提交到。数据库。合并。FB。好。这个时候看一下我们分支的状态啊,我们就说FA的一个特性分支开发完成了,我们合到了developb,这个特性分支它也开发完成了,合合并到了这个develop。对吧。这个时候啊。呃,FA如果想要继续开发新的功能,它可能要同步一下啊,这个develop分支这个代码,此时它就可以使用。我们切换到FA分值,就当我们合并完这个fap的代码之后,Develop的开发分值的代码已经是包含了它俩的代码,这个时候FA和FP都可能需要同步一下别人的一个代码,先切换到FA。然后使用。
16:01
啊,Develop去合并一下,让FA合并一下develop分支的代码。可以看到啊,这个时候已经包含了这个FB的一个内容,再切换到FB。让FB也合并一下develop的一个代码。Develop,这样的话,FA和FB的代码都是最新的一个代码,他们就可以继续去写其他的一个功能了。看下记录。好的,现在我们这个功能已经开发的差不多了。回到develop分支啊,功能已经开发的差不多了。啊,就是我们的这个功能啊,这些功能开发差不多,然后这是我们的代码也都写的差不多了,这个时候我们要准备进行发布了。啊,在发布之前呢。
17:03
要先。以这个。DV分支啊,Develop分支,开发分支为基础创建一个。Release分支。创建这个release分支。啊,之后我们在release分支上面进行进行测试啊,如果测试。嗯,发现了一个问题,就是在测试的这个期间,发现我们的这个有一个这个东西不想要,对吧?八我们不想要,我们就在这个release分子做一些调整。好,把它给删掉来。删掉这个之后,Release分支也进行提交。之后我们这个测试版本啊,在这个分支上测试已经发现没有任何问题了,就可以合并到master的分支。
18:09
先切到must的分支,然后在master分支合并这个release分支啊,这样的一个我们must分支这个代码就是可以发布到线上,可以发布运行的一个版本,对吧,但是因为我们在release分支做了调整,所以。底外的部分的作为,认为开发分支它也要去合并一下雷斯的一个调整,合并一下这个。嗯,优化后的啊,就是说修改了这个bug之后的一个调整,我们回到develop分支。嗯,G。磨叽一下。Release分支啊。好,可以发现减少了一条内容啊。
19:03
此时啊,我们回到master的分支。回到master分支,当must的分支,哎,正在运行的一个版本,突然发现了有紧急的一个bug要修复的话,而我们develop分支还有啊内容啊,正在开发,不适合发布一个新的版本,这时候我们就可以从ma的分支去切换出一个获fix分支去进行bug的一个修复。Checkout-B。Hot fix杠,比如说我们修修复一下这个登录的问题。一般修复的分值以这个hot fix开开头。好,现在我们就在这个,在这个分支上面,我们在这里面呢,去啊修改一下这个bug啊。比如说在这后边。修复问题保存。
20:03
之后进行一个提交,提交到我们的数据库。哎,测试没问题之后。回到must的分支,再合并这个。我们的。Bug修复分值。这样的话,我们的bug就进行修复了,但是我们的develop部分值肯定也存在这个bug,对不对,也需要这个bug的这个修复,此时我们最后再回到底的部分支。可以去。合并一下。八个分支啊,Hot fix分支。或者使用。
21:03
这个瑞贝我们同步一下,合并一下ma的最新的一个啊,历史记录状态也可以。好,现在看一下我们的历史记录已经和呃,Must是保持一致的,你看develop和must都是在一致的。都是在最新的这个。历史记录中。那么。当做完这个bug修复之后,其实这个hot fix这个分支已经没有用了,我们就可以把它给删掉,推塔B,三七杠D。Hot。好,此时再查看日志的一个状态,就没有了那个hot fix分支。这就是。呃,一个比较完整的,在实际。项目开发中实际的团队协作中的一个例子啊,关于各个分支的一个应用。
我来说两句