1

团队中git使用规范

 2 years ago
source link: https://lianpf.github.io/posts/%E5%BC%80%E5%8F%91%E6%97%A5%E8%AE%B0/02.%E5%9B%A2%E9%98%9F%E4%B8%ADgit%E4%BD%BF%E7%94%A8%E8%A7%84%E8%8C%83/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

团队开发中，遵循一个合理、清晰的 Git 使用流程，是非常重要的。 否则，各种不清晰的分支，再加上一堆杂乱无章的commit，在后续的查找定位问题和产品迭代维护会让你知道什么是头疼的。

如果项目中只有两三个人开发，其实也不需要严格的规范，只要把提交内容写清楚就行，但是大型项目，开发人员较多，规范提交还是有必要的

所以，我们会从以下几个方面来讲:

  • 分支命名规范
  • 分支使用规范(git-flow)
  • commit 规范

二、分支命名规范

(1) master 分支

  • master 为主分支，用于部署生产环境，要确保稳定性
  • master 分支一般由 develop 以及 hotfix 分支合并，任何时间都不能直接修改 master 分支代码
  • 每次更新master，都需对master添加指定格式的tag(git tag -a v0.0.1 -m “填写描述”)，用于发布或回滚

(2) develop 分支

  • develop 为开发分支，始终保持最新完成以及bug修复后的代码
  • 一般开发新功能时，feature 分支都是基于 develop 分支下创建的

(3) feature 分支

  • 开发新功能时，以 develop 分支为基础创建 feature 分支
  • 分支命名: feature/ 开头的为特性分支， 命名规则: feature/module_userName_date

例子： feature/lowCodeConfigs_yaoLing_20201015

(4) release 分支

  • release 为预发布分支，发布提测阶段，以 release 分支代码为基准提测

(5) hotfix 分支

  • 分支命名: hotfix/ 开头的为修复分支，它的命名规则与 feature 分支类似
  • 线上出现紧急问题时，需要及时修复，以 master 分支为基线，创建 hotfix 分支，修复完成后，需要合并到 master 分支和 develop 分支

三、分支使用规范(git-flow)

git-flow

新功能开发流程

  1. 从 develop 分支创建 feature 分支
  2. 开发调试完将 feature 分支提交到远程版本库
  3. 提交 pull request 请求 Merge 到 develop 分支
  4. 相关负责人 code review
  • 同意合并后，删除远程 feature 分支
  • 不同意，重新修改后上传 feature 分支，回到第3步执行
  1. 依赖develop分支构建测试环境，质量工程师功能测试验收
  • 测试问题直接在develop分支修复
  1. 测试环境验收通过，且合并develop分支至release分支，release分支填入最近"日常发布日"发布计划，发布预发环境，邀请产品和视觉团队验收
  • 预发问题在测试分支修复，修复完成后返回第5步
  1. 预发环境验收通过，发布日自动构建部署，正常发布。邀请产品团队生产验收，确认无误则合并release分支到master分支和develop分支

紧急问题修复流程

  1. 从 master 分支创建 hotfix 分支且申请填写“紧急发布计划”
  2. 修复完将 hotfix 分支提交到远程版本库
  3. 提交 pull request 请求 Merge 到 release 分支
  4. 相关负责人 code review
  • 同意合并后，删除远程 hotfix 分支
  • 不同意，重新修改后上传 hotfix 分支，回到第3步执行
  1. 依赖 release 分支构预发环境，质量工程师功能测试验收
  • 问题直接在 release 分支修复
  1. 预发环境验收通过，启动紧急发布计划自动构建部署，正常发布。邀请产品团队生产验收，确认无误则合并release分支到master分支和develop分支

注意：实际项目中，由于需求的复杂性，可能同时存在多个测试分支、预发分支

四、commit 规范

下面代码的 -m 参数，就是用来指定 commit message 的

$ git commit -m "commit message"

一般来说，commit message 应该清晰明了，说明本次提交的目的。而且多人协作的时候，有问题也方便查看提交日志。

如果一行不够，可以只执行git commit，就会跳出文本编辑器，让你写多行

目前，社区有多种 Commit message 的写法规范。来自Angular 规范是目前使用最广的写法，比较合理和系统化

参考 angular/angular.js commits 记录。

Commit message 包括三个部分：Header、Body 和 Footer

<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>

其中，Header 是必需的，Body 和 Footer 可以省略。为了避免自动换行影响美观，每部分，任何一行都不要有太多字符

1、Head

Header部分只有一行，包括三个字段：type（必填）、scope（影响范围，选填）和subject（必填）

type，必选
commit 的类别，只允许使用以下标识（或用对应的 emoji 表情，在前边再加一个: 就会显示了）

  • feat：新增功能（✨）
  • fix：修补bug（ 🚑）
  • docs：修改文档（📚）
  • style： 格式化代码结构，无逻辑上的代码修改（🎨)
  • refactor：重构，即不是新增功能，也不是修改bug的代码变动，比如重命名变量（🚜）
  • test：增加测试代码，单元测试一类的，没有生产代码的变更（🔬）
  • chore：构建过程或辅助工具的变动（不会影响代码运行）
  • revert：回滚到上一个版本。
  • merge：代码合并。
  • sync：同步主线或分支的Bug

特殊情况，当前 commit 用于撤销以前的 commit，则必须以revert:开头，后面跟着被撤销 Commit 的 Header

revert: feat: 设计器 Configs 基础配置
This reverts commit 660ecc1654a317a13331b17617d973392f418f02

推荐一个编写 Commit message 的工具 Commitizen

scope: 可选。用于定义 type 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同

subject: 必选。commit目的的简短描述，不超过50个字符

2、Body
Body 部分是对本次 commit 的详细描述，可以分成多行，每行尽量不超过72个字符

3、Footer
Footer 部分只用于两种情况:

  • 不兼容变动: 如果当前代码与上一个版本不兼容，则 Footer 部分以BREAKING CHANGE开头，后面是对变动的描述、以及变动理由和迁移方法
  • 关闭 Issue：如果当前 commit 针对某个issue，那么可以在 Footer 部分关闭这个 issue
Closes #234
Closes #123, #245, #992

示例

  • feat: 设计器 Configs 基础配置
  • fix: 修复Container Page特殊属性联动切换问题
  • style: delete 冗余联调阶段debugger
  • docs: 更新api文档
  • chore: 升级 monaco-editor 及对应babel 插件包版本
  • refactor: 重构Configs 方案（预设->动态拓展）

最后， 希望大家早日实现：成为前端高手的伟大梦想！
欢迎交流~

微信公众号

report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK