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 的特点,我们建议大家积极尝试文中所说的各种方法,可以带来如下一些优势:

  • 功能相互隔离。开发人员可以独立的变更功能,使得团队集成工作更加轻松,或者代码的合并加频繁。
  • 功能相互独立,在每个发布的新版本中可以挑选想要发布的功能,同时可以支持我们持续发布新的功能。
  • 更多、更合规的代码复查工作。
  • 自动化测试、部署和交付到各个环境。
目录
相关文章
|
2月前
|
图形学 开发工具 git
Unity与版本控制:游戏开发团队如何利用Git打造高效协作流程,实现代码管理的最佳实践指南
【8月更文挑战第31天】版本控制在软件开发中至关重要,尤其在Unity游戏开发中,能提升团队协作效率并避免错误。本文介绍如何在Unity项目中应用版本控制的最佳实践,包括选择Git、配置项目以排除不必要的文件、组织项目结构、避免冲突、规范提交信息以及使用分支管理开发流程,从而提高代码质量和团队协作效率。
219 1
|
3月前
|
消息中间件 小程序 Java
【规范】看看人家Git提交描述,那叫一个规矩
本文通过IDEA中的Git描述规范插件【git commit message helper】,介绍了Git提交描述的规范流程,强调了团队开发中统一标准的重要性,并通过实例展示了规范的提交记录如何提高代码管理和维护效率。最后,文章提供了几个实用的Git提交描述案例,帮助读者更好地理解和应用这些规范。
78 0
【规范】看看人家Git提交描述,那叫一个规矩
|
3月前
|
敏捷开发 小程序 持续交付
【规范】Git分支管理,看看我司是咋整的
本文介绍了Git分支管理规范的重要性及其在企业中的应用。通过规范化的分支管理,可加速团队协作、确保代码质量、维护主分支稳定,并支持敏捷开发。文中详细描述了主分支(如master、develop)和辅助分支(如feature、hotfix)的作用,并提供了实际开发流程示例,包括开发前、开发中、提测、预生产和部署上线等阶段的操作方法。旨在帮助团队提高效率和代码质量。
177 0
【规范】Git分支管理,看看我司是咋整的
|
3月前
|
开发工具 git
Git——commit的提交规范
Git——commit的提交规范
106 4
|
3月前
|
存储 测试技术 开发工具
企业Git 规范的必要性-阿里云开发者社区
既然认同需要一份 Git 规范,那么这个规范需要规范哪些内容,解决哪些问题。
|
3月前
|
监控 程序员 开发工具
如何规范Git提交-参考阿里云开发者社区
这篇文章分享了如何规范Git提交,介绍了commit message的格式规范,并通过webhook监控机制来确保代码提交的规范性,从而提高研发效率和代码维护质量。
|
3月前
|
开发工具 git
Git——简单的分支规范
Git——简单的分支规范
42 0
|
Java BI 开发工具
关于Git提交规范
自古至今,无规矩不成方圆。 Git提交也有其规范,业内做的比较好的,比较具有参考价值的就是Angular的提交。 Angular提交规范: (): #header // 空一行 // 空一行 格式讲解 Header Header部分只有一行,包括三个字段:type(必需)、scope(可选)和subject(必需)。
5494 0
|
18天前
|
缓存 Java Shell
[Git]入门及其常用命令
本文介绍了 Git 的基本概念和常用命令,包括配置、分支管理、日志查看、版本回退等。特别讲解了如何部分拉取代码、暂存代码、删除日志等特殊需求的操作。通过实例和图解,帮助读者更好地理解和使用 Git。文章强调了 Git 的细节和注意事项,适合初学者和有一定基础的开发者参考。
40 1
[Git]入门及其常用命令
|
1月前
|
开发工具 git
git学习四:常用命令总结,包括创建基本命令,分支操作,合并命令,压缩命令,回溯历史命令,拉取命令
这篇文章是关于Git常用命令的总结,包括初始化配置、基本提交、分支操作、合并、压缩历史、推送和拉取远程仓库等操作的详细说明。
113 1
git学习四:常用命令总结,包括创建基本命令,分支操作,合并命令,压缩命令,回溯历史命令,拉取命令