您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 Code iProcess 课程 认证 咨询 工具 火云堂 讲座吧   成长之路  
会员   
 
   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
     
   
 订阅
  捐助
GIT教程 -分支管理
 
来源:csdn 发布于: 2017-11-8
1242 次浏览     评价:      
 

浅析分支管理

我们在以前GIT版本回退当中我们明白了GIT本地存储的时间线,并且对它的底层原理具有一定的理解和认识,就是下图这个样子:

当然由于我们是进行演示的所以就只有一个master主分支,其实在一个大型项目中那时候相当多数目的分支的,有的人要那么多分支有什么用?

分支的用处其实就是多人协同合作的核心. 下面一张图帮我们理解分支的作用.

假设有三个平行世界,而你一无所知刚上大学,在三个平行空间里面你分别学习了C++,java,pathon 突然有一天宇宙能量失衡了,三个平行宇宙合体

了,这个时候的你就是精通C++,java,pathon的编程大佬. 其实这个事例就是分支的作用,在不同的地方开发,然后最后合并到主分支了,大家一起协

同维护主分支的代码. 通常我们刚开始创建一个本地库的时候,git会自主创建一个master分支(也就是我们的主分支),然后我们也可以创建其他分支.

在其他分支上面作业,最后一起合并到主分支之上!

分支的创建

刚刚我们已经见识到,GIT本地库的时间线,其实这个事件线就是一条分支. 截止到目前,只有一条时间线.但是在GIT当中,这个分支叫做主分支,既

master分支.HEAD严格来说不是指向提交,而是指向master,master才是指向提交的,所以,HEAD指向的就是当前分支.

我们来看看添加一个分支dev的过程:

一开始的时候,master分支是一条线,GIT用master指向最新的提交,再用HEAD指向master,就能确定当前分支,以及当前分支的提交点:

上面我们知道从现在开始对工作区的提交和修改就是针对dev分支了,比如新提交一次后,dev指针往前移动一步,而master指针不变:

假如我们再dev上的工作完成了,就可以吧dev合并到master上.最简单的方法就是如图所示,直接把master指向dev的当前提交,就完成合并.

所以GIT分支合并很快!也就是改改指针,工作区内容也不变. 合并完分之后,一般来说dev分支就没有存在的理由了,所以为我们正好删除掉dev分

支,删除dev分支就是将dev指针删除掉. 删除后,我们就剩下一条master分支:

我们现在都已经get到了分支合并的原理,现在我们开始学习命令,这里主要列出查看分支,创建分支,切换分支,删除分支,以及合并分支:

创建一条分支:$ git branch xxx

查看一条分支: $ git branch

切换到一条分支: $ git checkout xxx

代码演示:

其实你也可以这样,创建一个分支并且切换到该分支上: $ git checkout -b xxx

合并其他分支到该分支上面: $ git merge xxx 注意这里合并方式有很多种,现在我们看到的是Fast-forward合并,也就是合并为"快进形式".也就是

直接把master指向dev的当前提交,所以合并速度非常快. 当然不是每次合并都能Fast-forward,其他的在后面.现在我们将分支切回master,然后合并

最后一个就是删除分支了,命令很简单: $ git branch -d xxx 下面演示:

因为分支的执行效率非常高,并且它的创建,合并,删除都非常的快,所以GIT鼓励你使用分支完成某个任务,合并后再删除分支,这和直接在master

分支上工作效果是一样的,但过程更安全.

分支冲突

当我们沉浸在合并分支的高效和完美的时候,有没有人想过如果两个分支是一个对立面他们合并好了会怎么样?? 比如第一世界的小亮是一个正义的

警察,而在第二世界是一个毒枭.... 这个时候,你突然将第一世界和第二世界合并那么这个小亮很大概率是一个多重人格的精神疾病患者了. 所以合

并分支,也会出现这种情况,也就是我们说过的分支冲突,所以我们来看看如何来解决这个分支冲突呢??

我们同时分别在我GIT下面的MT和master分支上面提交了liang.txt,并且提交的内容还不一样...

master的提交:

MT的提交:

现在我们看来目前为止我们的分支示意图是这样的->>>>>>>>>

这个时候,我们来尝试一下切换回主分支,然后将分支合并,尝试让我们的master分支"人格分裂"一下:

我们发现GIT不允许"人格分裂"产生,并且还帮你找到了你在哪里分裂,让我们去文件里面修改,然后只留下来一个"人格",这个时候你只能乖乖回到文

件里面,然后做出取舍将文件重新修改,并且重新git add以及git commit,这个时候其实文件已经合并结束了,也就是下图那个样子:

这个时候肯定会有人不相信,凭什么你说的我都要相信,不要以为画了几张图我就相信你(手动微笑)! 好,有质疑心没问题! 还记得我们的git log

命令吗? 接下来 我们来看看git bash上面直观的分支冲突解决之后的样子!!

最后我们再删除掉MT分支,一次完美的分支合并就结束了. 目前为止,我们对分支有了自己的理解和认识,并且可以自己创建一个分支,自己切换分支

然后合并分支,以及解决掉合并分支中的分支冲突问题. 但这些只能让你熟悉分支的用法,但并不能让你理解分支在大家合作当中是如何使用的,所以下

一个博客当中,就会有分支的管理策略,以及BUG分支,Feature分支的应用. 更加偏重于实际运用当中的用法. 但是这些都前提都是,你要熟悉分支的

基本操作.

分支管理

我们在上一篇博客分支的基本操作当中已经学会了,创建,查看,切换,合并,删除一个分支, 那么既然我们拥有了基础的知识之后,那我们需要如何

实际运用分支呢? 那么在这个博客我们就能够找到答案. 通常,合并分支时,如果可能的话,GIT会用Fast forword模式,但是在这种模式下,删除分

支后,会丢掉分支信息.如果要强制禁用Fast forward模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支的信息.

然后我们可以直接先使用文字,陈述一下我们的过程,首先我们创建一个MT分支: $ git checkout -b MT 然后在分支上面修改liang.txt文件,然后进

行git add和git commit操作,然后切回主分支master,准备合并dev分支,请注意--no-ff参数,表示禁用Fast forward 然后在程序运行结束后我们再

使用git log指令查看分支的历史情况,所以过程就是这样,我们来看看代码实现:

其实这里我们只需要注意合并前的最后一行即可. 不使用Fast forward模式的话,merge之后就是这样了:

我们在实际开发当中,首先master分支应该是非常稳定的,也就是仅仅用来发布新版本,平时不能在上面干活; 干活都在另外一个备用的稳定分支之上

先叫他develop分支,平时都是这样比如要发布3.0版本时,先把develop分支合并到master分支上面,然后在master分支之上发布3.0版本.

然后平时在公司,你和你的程序猿朋友们都拥有各自的分支,当你写好代码你就往develop上面添加就OK了.所以团队合作的分支就像是下面这个图片:

bug分支

我们现在没写过多少程序也会发现,程序的bug简直就跟吃饭一样,闲了没事了就来一个BUG. 所以你这整个分支上肯定会不定时的出现各种各样的bug

这个时候,GIT岂能坐视不管,由于分支功能很强大,所以有bug我们完全可以通过一个新的临时的分支来修复,修复后,合并分支,然后将临时的分支

删除. 举个例子现在你在你自己的分支里面正在工作,然后你的老板突然打电话过来说master分支上面你负责的哪一个板块出现了bug,快赶紧过去抢

修,这个时候你就得马上放下手头的工作去修bug,但是我的工作这才写了一半,这里不用担心. 我们GIT有一个stash功能,可以把工作现场"储存"起

来,等以后恢复现场之后继续工作: $ git stash

好了,我们现在过来修改bug了,其实我们在上面那个图当中其实已经可以看到修改bug的过程了,具体就分为下面这几步:

假定我们在master分支上面修复,就从master创建临时分支bug-001. 然后修改bug,在文件中操作知道bug消除. 然后在该分支上面git add和git

commit,然后,切换回master分支,然后把bug-001分支合并到master分支上,这个时候master上面的bug解除了. 最后删除掉bug-001分支.

当然工程当中都是类似的修改bug方式,只是我的这个是在本地库修改. 然后当我们修改完bug.我们重新开始回到自己的分支上面干活,刚刚我

们使用$git stash 保存了工作现场. 我们可以使用$git stash list查看stash存储的工作现场. 接下来我们使用指令进行工作现场恢复:

$git stash apply //恢复现场,但是stash存储工作现场内容不删除

$git stash deop //删除git当中,stash指令存储的工作现场.

还有一种方式就是使用: $ git stash pop,//恢复的同时把stash内容也删了.

修复bug时,我们会通过创建新的bug分支进行修复,然后合并,最后删除. 但手头工作没有完成时,先把工作现场

git stash一下,然后修复bug,修复后再git stash pop,回到工作现场.

Feature分支

软件开发当中,总会有新的功能需要添加进来这个时候. 添加一个新功能时,你肯定不希望因为一些实验性质代码,把主分支搞乱了.所以,每添加一

个新功能,最好新建一个feature分支,在上面开发,完成后,合并,最后删除该feature分支.

从我上面那个图可以看出,创建一个feature分支的时候,其实跟bug分支没有什么区别,所以我们代码演示这个过程:

其实我们看到feature分支实现我们很容易理解的,我们只需要知道它的应用场景. 以及它的用法. 不过当你开发出新功能之后,你的组织上面突然有发

现了新功能的致命缺点,然后就让不要去往主分支上面合并了. 那你就只能删除这个分支了. 不过在GIT上面我们新创建的分支没有合并之前是没有办

法删除的. 所以我们需要一条大招指令: $git branch -D xxx //强行删除

所以要丢弃一个没有被合并过的分支,可以通过git branch -D xxx 进行强行删除...

   
1243 次浏览  评价: 差  订阅 捐助
相关文章

每日构建解决方案
如何制定有效的配置管理流程
配置管理主要活动及实现方法
构建管理入门
相关文档

配置管理流程
配置管理白皮书
CM09_C配置管理标准
使用SVN进行版本控制
相关课程

配置管理实践
配置管理方法、工具与应用
多层次集成配置管理
产品发布管理
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号