Code Better

切换日光/暗黑模式

规范 ​

分支管理流程规范 ​

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 的格式 ​

jsx
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

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

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

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 部分以 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小标题下面。

©2024 Dancy Su