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

1元 10元 50元





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



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
   
 
 
     
   
 订阅
  捐助
Git代码分支管理在项目中的实践
 
作者 :揸沽神  来源:博客 发布于 2016-8-29
   次浏览      
 

Git是一个非常强大的分布式版本管理工具,分布式简单的理解就是在本地也会copy一份代码数据,用户机器可以当作一台本地服务器,用于代码的离线的提交,即你坐在青海湖边在没网络的情况下也可以提交自己的代码,想想就流逼,但是真正提交到中央仓库还是需要网络才行,不过这个功能已经可以让大家不受中央集群的服务状态影响,即使挂掉了自己还可以进行代码提交,等服务器正常后再次提交即可,本文不讲述git与svn的区别,如果想大概了解的话可以查看《git与svn的区别》,下面主要讲述git分支管理在项目中的实际使用。

主要分为以下四大分支:

1.master

2.dev

3.test

4.bugfix(可不用)

一、master(主分支)

当代码克隆下来后默认就是这个分支,也就是所谓的主分支,可以认为该分支是存储当前功能测试通过且可运行的正式代码,所以一般不会直接在主分支上进行开发,这个是核心分支,也就是主路径,所有最后的代码都必须合并到主路径上,如果发布到生产环境必须通过master分支进行打包,这是代码管理非常重要的一步,即使线上代码出现问题后也可以迅速通过主分支进行代码修复,保证不会出错,也保证修复的是与线上正在的运行代码同步的。

git clone xxxxxxxx.git  

master的版本管理直接用tag功能即可,即通过打tag的方式表示当前可以上线的一个版本,也方便以后进行对应版本的数据查询或者比较,如v1.0.0-publish,v2.0.0-publish等

二、dev(开发分支)

开发分支是研发同学最需要关心的,所有的开发工作应该围绕dev分支进行展开,创建dev分支脚本如下:

git checkout -b dev master 

dev分支在实际工作中主要有两种常用场景:

1.单个版本开发

2.多个版本并行开发

针对第一种情况,属于比较常见的情况,即开发过程中都是按顺序进行的,即1.0.0开发完成之后才会进行开发1.1.0的需求开发,1.1.0完成上线后再进行1.2.0的版本开发,针对这种,工作直接在dev分支上开展就可以了,不需要做特殊处理,因为不会产生任何干扰~~

相关操作脚本:

git checkout -b dev master 

针对第二种情况,可能在互联网公司会比较常见,在开发资源比较充足的情况下,多个版本可能同时并行,即1.1.0和1.2.0或者更多版本在同时开发,但是又想快速试水一些功能,不可能等到全部做完都上线,所以1.1.0会先发,1.2.0会在另外一个时间点发,产品经理通常会很着急,认为错过这个时间点就会损失十几亿的感觉,碎碎的忧伤,所以分支的合理管理非常重要,不然在开发过程中会显得非常混乱,如果都在dev分支上进行开发就会把没做完的功能都发线上了,这时候就更碎了~~~ git 也给我们使用feature功能模式,即功能分支,可以通过这个来划分,如下:

先创建两个feature分支,跟创建dev分支一样,不过这次是从dev分支进行创建

git checkout -b feature-1.1 dev  
git checkout -b feature-1.2 dev

开发1.1.0版本操作的相关脚本:

git checkout -b feature-1.1 dev  
git checkout -b feature-1.2 dev

开发1.2.0版本操作的相关脚本:

git checkout feature-1.2  

#又是各种commit push操作,开发完成测试通过后执行下面操作,合并代码到dev分支:
git checkout dev
git pull origin dev
git merge --no-ff feature-1.2
git push

#删除本地feature分支
git branch -d feature-1.2
#删除远程feature分支
git push origin --delete feature-1.2

分支切换流程图如下:

三、test(测试分支)

测试分支很明显是给测试同学使用的,主要是开发同学认为在开发分支上进行测试通过后可以合并到test分支上,提给测试同学测试,如果需要简单一点的分支管理结构可以把test分支去除,因为加了一层之后合并的操作可能会增加,不过这块可以保证合并到主干的代码都是统一由测试同学测试通过后合并,因为dev分支一直都可以添加新代码,当增加新代码后必须要测试才可以上线,所以才会产生了test分支,创建分支的脚本如下:

git checkout -b test master 

分支合并操作跟上面的操作脚本相似,这里面就不一一列出了,大概的执行路径如下图:

四、bugfix分支(bug修复分支)【可不用】

紧急修复线上bug的时候使用,但是一般场景的话直接在master上修复即可了,因为bug一般都是要立即解决,切个分支来做还会增加成本,所以可以不用单独切个分支出来,如果要使用的话其实也是从master上打个分支出来,修复完后直接合并到master上,分支创建脚本如下:

git checkout -b bugfix master 

具体切换流程如下:

现在在项目中主要是使用dev - test -master的模式,大家也可以使用这种方式进行分支管理,让你的代码库更加有序,上面有说的不对或者写错的地方,麻烦大家在评论中指出,或者有更好的管理方法也可以一起交流~~~

   
次浏览       
相关文章

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

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

配置管理实践
配置管理方法、工具与应用
多层次集成配置管理
产品发布管理
最新活动计划
LLM大模型应用与项目构建 12-26[特惠]
QT应用开发 11-21[线上]
C++高级编程 11-27[北京]
业务建模&领域驱动设计 11-15[北京]
用户研究与用户建模 11-21[北京]
SysML和EA进行系统设计建模 11-28[北京]

软件配置管理的问题、目的
软件配置管理规范
CQWeb 7.1性能测试与调优指南
为什么需要使用ClearCase
ClearCase与RTC的集成
利用ClearQuest 进行测试管理
更多...   

产品发布管理
配置管理方法、实践、工具
多层次集成配置管理
使用CC与CQ进行项目实践
CVS与配置管理
Subversion管理员

配置管理实践(从组织级到项目级)
通号院 配置管理规范与应用
配置管理日构建及持续集成
丹佛斯 ClearCase与配置管理
中国移动 软件配置管理
中国银行 软件配置管理
天津华翼蓝天科技 配置管理与Pvcs