CodeBetter
工程化
性能优化
云服务器
项目笔记
三方库
其它
工程化
性能优化
云服务器
项目笔记
三方库
其它

规范

分支管理流程规范

GitFlow 模型

适用于团队技术水平适中,有一定开发流程和规范的团队。

  • master / main：主线/基线分支
    • 【核心分支】它包含了项目的最新稳定版本的代码,所以应该随时保证主线分支中的代码是可发布的。
    • 一般来说主线分支的代码会被部署到生产环境中
    • 主线分支中的代码是不允许直接修改的,只能通过合并分支的方式来修改（只接受来自 hotfix 和 release 的合并请求）,每次合并分支都建议生成一个新的版本号,这样可以方便追踪和回溯,可以通过 git tag 命令来标记版本号。
      • 版本号规则：
        • 主版本（Major Version）：主要的功能变化或重大更新
        • 次版本（Minor Version）：一些新的功能、改进和更新,通常不会影响现有功能
        • 修订版本（Patch Version）：一些小的bug修复,安全漏洞补丁等,通常不会更改现有功能和接口。
  • hotfix：线上版本bug热修复分支
    • 【辅助分支】从main分支pull出来,用于解决线上问题,修复完成后合并回main分支和develop分支中
    • 发布小版本,删除掉该分支。
    • 命名规则：hotfix-#issueid-desc
  • release：预发布分支
    • 【辅助分支】用于发布前的测试和验证
    • 只提交测试过程中发现的 BugFix 内容
    • 发布分支应该从开发分支派生,并在准备好发布版本后合并回主分支和开发分支。
  • develop：开发分支
    • 【核心分支】用于日常开发,所有的功能分支、发布分支、修补分支都应该从开发分支派生出来。
  • feature：功能分支
    • 【辅助分支】用于开发单独的功能或者特性。
    • 每个功能分支都应该从开发分支派生,并在开发完成后合并回开发分支。

GitHub Flow 模型

适用于一些技术水平比较高的团队或开源项目。

  • master：主分支
    • 主分支上的代码是可以直接部署到生产环境中
    • 一般会设置分支保护,禁止团队成员直接在主分支上进行提交。
  • feature：

    • 团队成员们可以分主分支中分离出自己的分支进行开发和测试,然后本地分支提交代码,等到开发完成之后可以发起一个 Pull Request（拉请求/合并请求）。团队成员们可以对代码进行 Review 评审,如果没有问题就可以将这个 PR 发布（Deploy）和合并（Merge）到主分支中。

分支命名规范

在命名方面推荐使用带有意义的描述性名称来命名分支

  • 版本发布分支/Tag示例：v1.0.0
  • 功能分支示例：feature-login-page
  • 修复分支示例：hotfix-#issueid-desc

分支创建规范

  • 定期合并已成功验证的分支,及时删除已经合并的分支

  • 保持合适的分支数量

  • 为分支设置合适的管理权限

git message规范

公认的 git message 规范是 angular规范。

commit message 的格式

1<type>(<scope>): <subject>
2<BLANK LINE>
3<body>
4<BLANK LINE>
5<footer>

其中,header 是必须的,body 和 footer 可以省略。

不管哪一部分,任何一行都不得超过72个字符（或100个字符）,这是为了避免自动换行影响美观。

Header

Header部分只有一行,包括三个字短：type（必需）、scope（可选）和 subjet（必需）。

type

用于说明 commit 的类别,只允许使用下面 7 个标识：

  • feat：新功能（feature）
  • fix：修补bug
  • docs：文档（documentation）
  • style：格式（不影响代码运行的变动）
  • refactor：重构（既不是新增功能,也不是修改bug的代码变动）
  • test：增加测试
  • chore：构建过程或辅助工具变动

如果 type 为 feat和fix,则该commit将肯定出现在 Change log之中。

其他情况（docs、style、test、chore）由你决定,要不要放入 Change log,建议是不要。

scope

scope用于说明 commit 影响的范围,比如数据层、控制层、视图层等等,试项目不同而不同。

例如在Angular,可以是 $location, $browser, $compile, $rootScope, ngHref, ngClick, ngView 等。

如果你的修改影响了不只一个 scope,你可以使用 * 代替。

subject

subject是 commit 目的的简短描述,不超过50个字符

  • 以动词开头,使用第一人称现在时,比如 change,而不是 changed 或 changes。
  • 第一个字母小写
  • 结尾不加句号（.）

Body

body 部分是对本次 commit 的详细描述,可以分成多行。

  • 使用第一人称现在时,比如 change,而不是 changed 或 changes。

  • 永远别忘了第二行是空行

  • 应该说明代码变动的动机,以及与以前行为的对比。

Footer

Footer 部分只用于以下两种情况

不兼容变动

如果当前代码与上一个版本不兼容,则 Footer 部分以 BREAKING CHANGE 开头,后面是对变动的描述,以及变动理由和迁移方法。

关闭Issue

如果当前 commit 针对某个 issue,那么在 Footer 部分关闭这个 issue。

Revert

还有一种特殊情况,如果当前 commit 用于撤销以前的 commit,则必须以 revert: 开头,后面跟着被撤销 commit 的 Header。

revert: feat(pencil): add .... This reverts commit ...

Body部分的格式是固定的,必需写成 This reverts commit <hash>,其中 hash 是被撤销 commit 的 SHA 标识。

如果当前 commit 与被撤销的 commit,在同一个发布（release）里面,那么它们都不会出现在 Change log 里面。如果两者在不同的发布,那么当前 commit,会出现在 Change log 的 Reverts小标题下面。