git分支管理规范（摘抄）

分支管理规范

  • master分支

    • 主分支，永远处于稳定状态，对应当前线上版本
    • 以 tag 标记一个版本，因此在 master 分支上看到的每一个 tag 都应该对应一个线上版本
    • 不允许在该分支直接提交代码，只允许release分支合并或者hotfix分支合并

  • develop 分支

    • 开发分支，包含了项目最新的功能和代码，所有开发都依赖 develop 分支进行
    • 小的改动可以直接在 develop 分支进行，改动较多时切出新的 feature 分支进行

    注： 更好的做法是 develop 分支作为开发的主分支，也不允许直接提交代码。小改动也应该以 feature 分支提 merge request 合并，目的是保证每个改动都经过了强制代码 review，降低代码风险

  • feature 分支

    • 功能分支，开发新功能的分支
    • 开发新的功能或者改动较大的调整，从 develop 分支切换出 feature 分支，分支名称为 feature/idxxx
    • 开发完成后合并回 develop 分支并且删除该 feature/idxxx 分支

  • release 分支

    • 这是发布分支，新功能合并到 develop 分支后，基于 develop 分支准备发布新版本时使用的分支
    • 当 develop 分支完成功能合并和部分 bug fix，准备发布新版本时，切出一个 release 分支，来做发布前的准备，分支名约定为release/xxx
    • 发布之前发现的 bug 就直接在这个分支上修复，确定准备发版本就合并到 master 分支，完成发布，同时合并到 develop 分支

  • hotfix 分支

    • 紧急修复线上 bug 分支
    • 当线上版本出现 bug 时，从 master 分支切出一个 hotfix/xxx 分支，完成 bug 修复，然后将 hotfix/xxx 合并到 master 和 develop 分支(如果此时存在 release 分支，则应该合并到 release 分支)，合并完成后删除该 hotfix/xxx 分支

概述

以上就是在项目中应该出现的分支以及每个分支功能的说明。 其中稳定长期存在的分支只有 master 和 develop 分支，别的分支在完成对应的使命之后都会合并到这两个分支然后被删除。简单总结如下：

  • master 分支: 线上稳定版本分支

  • develop 分支: 开发分支，衍生出 feature 分支和 release 分支

  • release 分支: 发布分支，准备待发布版本的分支，存在多个，版本发布之后删除

  • feature 分支: 功能分支，完成特定功能开发的分支，存在多个，功能合并之后删除

  • hotfix 分支: 紧急热修复分支，存在多个，紧急版本发布之后删除

流程

提交规范

听说用的比较多的是Angular的标准

<type>(<scope>): <subject> 
<BLANK LINE> 
<body> 
<BLANK LINE> 
<footer>
  • type: 本次 commit 的类型，诸如 bugfix docs style 等，在下方有说明
  • scope: 本次 commit 波及的范围
  • subject: 简明扼要的阐述下本次 commit 的主旨
    • 使用现在时的命令性语气 ，present tense: “change” not “changed” nor “changes”.
    • 首字母不要大写
    • 结尾无需添加标点
  • body: 应包括改变的动机，并将其与以前的行为进行对比。如需换行，则使用 |。
  • footer: 描述下与之关联的 issue 或 break change。可以附上issue链接。公司内部应该很少会用到

Type的类别说明：

  • feat: 添加新特性

  • fix: 修复bug

  • docs: 仅仅修改了文档

  • style: 仅仅修改了空格、格式缩进、都好等等，不改变代码逻辑

  • refactor: 代码重构，没有加新功能或者修复bug

  • perf: 增加代码进行性能测试

  • test: 增加测试用例

  • chore: 改变构建流程、或者增加依赖库、工具等

示例

也是最小需要的提交信息，至少需要type和commit

  • feat: 用户登录

  • fix: 用户权限bug

来源(略作修改)