在做项目的时候,不管是多人协作,还是单兵作战,都需要用版本管理工具对项目进行管理。市面上的版本管理工具很多,比如有我们比较熟悉的 svn 和 git。它们的优缺点,我们这边不做讨论,大家可以网上搜索。本文主要讨论 git 的一个显著优点:版本的分支管理。下面介绍的是一种实践中证明运行比较良好的版本分支管理方式。

主分支

在实际开发中,一个项目的仓库主要有两个主分支:masterdevelop 分支。这个两个分支伴随着整个项目周期。且不允许直接 push 到这两个分支上。

  • master:创建 git 仓库时自动生成的原始分支。
    这个分支代表项目处于可发布的状态。其他无关代码不得随便往 master 上合并。只有计划发布的版本功能在 develop 分支上全部完成,而且测试通过后才会合并到 master 上。
  • develop:基于 master 分支创建,与 master 分支平行,为开发的整合分支。
    主要来源为各程序员的开发功能分支的合并(Feature branches,下面会讲到)。

功能分支

除了上面的主分支外,我们在开发中还会用到其他功能分支,以帮助团队成员之间进行并行开发,简化功能跟踪,为生产发布做准备并协助快速解决生产中的实际问题。与主分支不同,这些分支的生命周期总是有限的,因为它们被合并后就会被删除。

  • Feature branches:功能分支。程序员在开发每个功能的时候都需要在各自的功能分支上开发。
    每次开发新功能都必须从 develop 分支创建,开发完成合并回到 develop 分支后删除。分支命名可以是除 master、develop、release-*、hotfix-* 外的任何内容,建议使用 feature-*(如 feature-register,代表用户注册的开发分支)。
  • Release branches:预发布分支。在 master 要发布正式版本之前(即合并到 master 分支之前),我们可能需要有一个预发布的版本进行测试。
    测试过程中如有小调整(比如调整位置、宽度,修改文案等不会引入新 bug),直接在该分支上修改。如果出现大 bug 必须通过创建 feature 分支,走正常流程。如果是一些无关紧要的小 bug,可以推迟到下个版本更新修复。
    预发布分支是基于 develop 分支创建,预发布结束以后,如有修改必须合并到 develop 和 master 分支。最后删除该分支。分支命名使用 release-*(如 release-0.1,即 release-预发布版本号)。正式发布时,一般会基于 master 分支创建一个 tag,命名为 tag-*(如 tag-0.1,即 tag-线上版本号)
  • Hotfix branches:线上 bug 修复分支。项目发布上线后,出现的 bug,在这个分支上修复。
    该分支基于线上版本对应的 master 分支(或 tag)创建,修复完 bug,必须合并到 develop 和 master 分支。最后删除该分支。分支命名使用 fixbug-*(如 fixbug-0.1,即 fixbug-线上版本号)。

总结图

参考文章:https://nvie.com/posts/a-successful-git-branching-model/

如果觉得我的文章对你有用,请点个赞