码迷,mamicode.com
首页 > 其他好文 > 详细

如何对Git的分支进行管理

时间:2020-06-25 21:11:10      阅读:56      评论:0      收藏:0      [点我收藏+]

标签:开发者   不能   ase   一个   部署   新功能   ESS   如何   状态   

前言

Git是一个很方便的版本管理工具,我所认识的大部分开发者都在使用Git,也正是由于其方便性,如果团队没有一个统一的分支管理策略,那么分支可能会非常混乱,开发者将因此花费额外的时间处理这方面的问题。在搜索引擎上搜索分支管理策略,大部分都指向Vincent Driessen提出的策略。我这里也记录一下,万一以后让公司让我写规范文档或者面试中问到,能够说的清楚系统一些。

介绍

技术图片

这个策略将分支分为了两个部分:

主要分支

主要分支有两个,长期存在。

Master

Master是用于部署生产环境的分支,有且只有一条。一般由develop分支合并,任何时间都不能直接修改代码。

Develop

develop 为开发分支,始终保持最新完成以及bug修复后的代码;

当develop分支的源码到达了一个稳定状态待发布,所有的代码变更需要以某种方式合并到master分支,然后标记一个版本号(TAG)。所以,每次变更都合并到了master,这就是新产品的定义。在这一点,我们倾向于严格执行这一点,从而,理论上,每当对master有一个提交操作,我们就可以使用Git钩子脚本来自动构建并且发布软件到生产服务器。

辅助分支

辅助性分支有三个,用后即删。

Feature:

开发新功能时,以Develop为基础创建feature分支,开发完成后,要再并入Develop。

分支命名: feature/ 开头的为特性分支;

命名规则: feature/user_module、 feature/cart_module;

Release:

release 为预上线分支,发布提测阶段,会release分支代码为基准提测;Release分支可能从develop分支分离而来,但是一定要合并到develop和master分支上,一般命名方式为:release/*。

当有一组feature开发完成,首先会合并到develop分支,进入提测时,会创建release分支。如果测试过程中若存在bug需要修复,则直接由开发者在release分支修复并提交。当测试完成之后,合并release分支到master和develop支, 此时master为最新代码,用作上线。

Hotfix :

分支命名: hotfix/ 开头的为修复分支,它的命名规则与 feature 分支类似,线上出现紧急问题时,需要及时修复,以master分支为基线,创建hotfix分支,修复完成后,需要合并到master分支和develop分支;

规则的一个例外是: 如果一个release分支已经存在,那么应该把hotfix合并到这个release分支,而不是合并到develop分支。当release分支完成后, 将bugfix分支合并回release分支也会使得bugfix被合并到develop分支。(如果在develop分支的工作急需这个bugfix,等不到release分支的完成,那你也可以把bugfix合并到develop分支)。

总结

这个管理策略的已经非常好了,可以直接拿来用,但是也没有必要完全照搬照抄,可以在此基础上或增或减,适合自己的项目和团队的才是最好的。用好分支管理,能够有效的提高版本管理的质量和效率,同时培养开发者思维习惯,让开发过程更优雅。

如何对Git的分支进行管理

标签:开发者   不能   ase   一个   部署   新功能   ESS   如何   状态   

原文地址:https://www.cnblogs.com/hanstrovsky/p/13192834.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!