Git Flow规范在工作中的使用流程

简介: Git Flow规范在工作中的使用流程

我们在进行项目开发的时候,为了更好的管理项目、追溯项目历史,我们会采用代码管理。一般常用的有 gitsvn 等,但是项目的开发、测试、上线往往都是有很多工作,如果没有一个合适的管理规范那会导致项目出现一下不必要的麻烦。可能各个公司有不同的管理方式,本文博主分享一下我们一直沿用的 GIT 分支管理规范。

开发者一般都是开发完功能提交代码,这个时候由专人、或是版本管理员,将所有新功能集成起来,解决代码的冲突、然后准备发布新的版本。代码的合并总是让人担惊受怕,在版本的测试、发布也会伴随着不可预见的错误,在 2000 年的时候,Kent Beck 发布了具有开创性的著作《Extreme Programming Explained》,其中提出了「持续集成」的概念,即开发人员需要每几个小时或最多一天内进行编译然后合并代码到主分支最后再运行自动化测试。

用张图给大家描述一下

开发人员提交到仓库 -> 触发 CI Server(持续集成服务器)的相关功能。执行 编译 -> 测试 -> 输出结果 的流程,向开发人员反馈结果的 report

这种方式可以大大减少我们的成本,我们只要做好 git 分支的管理,每种类型的分支对应不同的操作即可很轻易使用持续集成

初试Git Flow

我们公司采用的就是选择 git flow 工作流程来方便持续集成。就像代码需要代码规范一样,分支管理同样需要一个清晰的流程和规范

上图描绘了 git flow 的分支管理流程,不懂没关系,我们再来白话一下。

Git Flow常用的分支

  • Master 分支

这个分支的代码是发布到生产环境的代码,这个分支只能从其他分支合并,不能在这个分支直接修改

  • Develop 分支

这个分支是我们是我们的主开发分支,包含所有要发布到下一个Release的代码,这个主要合并与其他分支,比如Feature分支

  • Feature 分支

这个分支主要是用来开发一个新的功能,一旦开发完成,我们合并回Develop分支进入下一个Release

  • Release 分支

当你需要一个发布一个新Release的时候,我们基于Develop分支创建一个Release分支,完成Release后,我们合并到MasterDevelop分支

  • Hotfix 分支

当我们在Master发现新的Bug时候,我们需要创建一个Hotfix, 完成Hotfix后,我们合并回MasterDevelop分支,所以Hotfix的改动会进入下一个Release

Git flow工作流程

开始使用 Gitflow 之前,需要做一步一次性的初始化动作,就是从 master 分支上创建一个 develop 分支。自此,develop 分支将变成一个类似全能的分支,用来存放、测试所有的代码,同时也是主要是用来合并代码、集成功能的分支。

作为一个开发人员,在这是不允许直接提交代码到 develop 分支上的,更更更不允许直接提交到 master 分支

  • Master分支

所有在Master分支上的Commit应该Tag

  • 当我们分配开发一个新功能的时候 feature/分支

你需要立即从 delevop 分支上创建一个 feature 分支。在 feature 分支的命名规则上,我们可以以 feature/功能名 来命名功能分支,当功能完成的时候,必须合并到 develop 分支,合并完成一般删除掉功能分支,提交的分支最好一天内合并到 develop

  • 当我们开发完需要发布的时候 release/分支

当一期功能都开发完成都合并到 develop 后,我们基于 develop 分支创建一个 release/分支,我们可以在这个Release分支上测试,修改Bug等。同时,其它开发人员可以基于开发新的Feature (记住:一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支)

发布Release分支时,合并ReleaseMasterDevelop, 同时在Master分支上打个Tag记住Release版本号,然后可以删除Release分支了。

  • 当线上出现紧急情况需要修复的时候 hotfix/分支

hotfix分支基于Master分支创建,开发完后需要合并回MasterDevelop分支,同时在Master上打一个tag

如果我们嫌弃自己来创建这些分支很麻烦,我们可以使用 Git Flow 工具,下载地址 https://github.com/nvie/gitflow/wiki/Installation

真的好用,这个玩意还有可视化版本的,我一般使用 SourceTree

以上就是 Gitflow 的特点,我们建议大家积极尝试文中所说的各种方法,可以带来如下一些优势:

  • 功能相互隔离。开发人员可以独立的变更功能,使得团队集成工作更加轻松,或者代码的合并加频繁。
  • 功能相互独立,在每个发布的新版本中可以挑选想要发布的功能,同时可以支持我们持续发布新的功能。
  • 更多、更合规的代码复查工作。
  • 自动化测试、部署和交付到各个环境。
目录
相关文章
|
3月前
|
开发工具 git 开发者
百度搜索:蓝易云【Git实际开发的流程】
以上是Git在实际开发中的一般流程。Git的分布式版本控制系统使得团队开发更加高效和灵活,并能有效管理项目的版本历史。
31 1
|
1月前
|
弹性计算 开发工具 git
如何创建符合计算巢规范的Git仓库
为了简化软件云化部署,阿里云计算巢提供了一站式平台,开发者仅需将自己的git仓库配置为符合计算巢服务规范,即可实现自动化部署到云端。官方提供了多个模板,涵盖不同架构和部署物类型,便于开发者从计算巢官方仓库fork并定制。重要文件包含config.yaml和,用于配置服务构建参数。通过计算巢控制台,即可完成服务的创建和发布,实现软件的云上部署。
|
2月前
|
存储 开发工具 git
Git工作流程:如何在团队中协作?
Git工作流程:如何在团队中协作?
|
3月前
|
前端开发 测试技术 持续交付
【开发规范】Git Commit 规范
【1月更文挑战第26天】【开发规范】Git Commit 规范
|
3月前
|
存储 缓存 开发工具
Git 拉取合并代码流程和多人协同开发的问题解决方法
Git 拉取合并代码流程和多人协同开发的问题解决方法
66 0
|
3月前
|
网络安全 开发工具 git
Git在windows下上传文件至github流程
Git在windows下上传文件至github流程
22 0
|
3月前
|
数据可视化 测试技术 持续交付
Git Flow规范在工作中的使用流程
Git Flow规范在工作中的使用流程
39 0
|
Java BI 开发工具
关于Git提交规范
自古至今,无规矩不成方圆。 Git提交也有其规范,业内做的比较好的,比较具有参考价值的就是Angular的提交。 Angular提交规范: (): #header // 空一行 // 空一行 格式讲解 Header Header部分只有一行,包括三个字段:type(必需)、scope(可选)和subject(必需)。
5426 0
|
18天前
|
缓存 数据可视化 网络安全
Git命令大全
Git命令大全
52 1
|
22天前
|
开发工具 git
Git教程:深入了解删除分支的命令
【4月更文挑战第3天】
43 0
Git教程:深入了解删除分支的命令

相关实验场景

更多