5月21
# 你的默认全局账号
[user]
name = heck
email = i@heckjj.com
# ======================
# 自动切换 heckjj 账号
# ======================
[includeIf "hasconfig:remote.*.url:https://git.tencent.com/**"]
path = .gitconfig-tencent
最后一步：必须新建这个文件
打开文件夹：C:\Users\你的用户名\
新建一个文件，名字叫：
.gitconfig-tencent
内容只有这两行：
[user]
name = heck
email = heck@tencent.com
这样就自动生效了
所有 git.tencent.com 仓库 → 自动用 heck
其他所有仓库 → 用你的默认账号 heck
不用手动切换，不用每个仓库单独设置
[user]
name = heck
email = i@heckjj.com
# ======================
# 自动切换 heckjj 账号
# ======================
[includeIf "hasconfig:remote.*.url:https://git.tencent.com/**"]
path = .gitconfig-tencent
最后一步：必须新建这个文件
打开文件夹：C:\Users\你的用户名\
新建一个文件，名字叫：
.gitconfig-tencent
内容只有这两行：
[user]
name = heck
email = heck@tencent.com
这样就自动生效了
所有 git.tencent.com 仓库 → 自动用 heck
其他所有仓库 → 用你的默认账号 heck
不用手动切换，不用每个仓库单独设置
5月18
`git feat` 是指在 Git 提交（commit）信息中使用 `feat` 作为前缀，它是英文 “feature”（新功能）的缩写，用于标识本次提交新增了一个功能或特性。
这一用法源于 [Conventional Commits（约定式提交）](https://www.conventionalcommits.org/) 规范，该规范通过标准化提交信息格式，提升团队协作效率，并便于自动生成变更日志（changelog）和版本号管理。
---
常见提交类型前缀含义
- `feat`：新增功能（feature）
示例：`feat: 添加用户登录功能`
- `fix`：修复 bug
示例：`fix: 修复登录超时问题`
- `docs`：仅修改文档
示例：`docs: 更新 README 使用说明`
- `style`：代码样式调整（不影响运行）
示例：`style: 格式化代码缩进`
- `refactor`：代码重构（非新增功能、非修复 bug）
示例：`refactor: 提取用户验证逻辑为独立函数`
- `chore`：构建过程或工具依赖更新
示例：`chore: 更新 npm 依赖包`
- `test`：增加或修改测试
示例：`test: 添加登录接口单元测试`
---
提交信息结构（Conventional Commits）
标准格式为：
```
():
[body]
[footer]
```
- `type`：必须，如 `feat`、`fix` 等
- `scope`：可选，限定影响范围，如 `(auth)`、`(api)`
- `subject`：简短描述（≤50 字符）
- `body` / `footer`：可选，详细说明或关联 issue
示例完整写法：
```bash
feat(auth): 添加 Google OAuth 登录支持
- 允许用户通过 Google 账号一键登录
- 集成 OAuth2.0 流程
- 关联 JIRA-123
```
---
实践意义
- ✅ 提高可读性：团队成员快速理解提交目的
- ✅ 支持自动化：工具（如 `semantic-release`）可依据 `feat` 自动升级版本号
- ✅ 便于生成 changelog：按类型分类生成发布说明
更多规范细节可参考：[Conventional Commits 官方规范](https://www.conventionalcommits.org/)
这一用法源于 [Conventional Commits（约定式提交）](https://www.conventionalcommits.org/) 规范，该规范通过标准化提交信息格式，提升团队协作效率，并便于自动生成变更日志（changelog）和版本号管理。
---
常见提交类型前缀含义
- `feat`：新增功能（feature）
示例：`feat: 添加用户登录功能`
- `fix`：修复 bug
示例：`fix: 修复登录超时问题`
- `docs`：仅修改文档
示例：`docs: 更新 README 使用说明`
- `style`：代码样式调整（不影响运行）
示例：`style: 格式化代码缩进`
- `refactor`：代码重构（非新增功能、非修复 bug）
示例：`refactor: 提取用户验证逻辑为独立函数`
- `chore`：构建过程或工具依赖更新
示例：`chore: 更新 npm 依赖包`
- `test`：增加或修改测试
示例：`test: 添加登录接口单元测试`
---
提交信息结构（Conventional Commits）
标准格式为：
```
[body]
[footer]
```
- `type`：必须，如 `feat`、`fix` 等
- `scope`：可选，限定影响范围，如 `(auth)`、`(api)`
- `subject`：简短描述（≤50 字符）
- `body` / `footer`：可选，详细说明或关联 issue
示例完整写法：
```bash
feat(auth): 添加 Google OAuth 登录支持
- 允许用户通过 Google 账号一键登录
- 集成 OAuth2.0 流程
- 关联 JIRA-123
```
---
实践意义
- ✅ 提高可读性：团队成员快速理解提交目的
- ✅ 支持自动化：工具（如 `semantic-release`）可依据 `feat` 自动升级版本号
- ✅ 便于生成 changelog：按类型分类生成发布说明
更多规范细节可参考：[Conventional Commits 官方规范](https://www.conventionalcommits.org/)
5月18
本文档定义了团队使用 Git 的标准流程和规范，所有团队成员必须遵循。
版本：v1.0.0
最后更新：2026年
适用范围：所有项目
目录
分支管理规范
提交信息规范
工作流程规范
代码审查规范
命名规范
安全规范
工具与配置
常见场景处理
1. 分支管理规范
1.1 分支类型
主分支（Main Branches）
main / master
用途：生产环境代码
保护：✅ 必须通过 Pull Request 合并
禁止：❌ 禁止直接推送，禁止强制推送
develop
用途：开发环境代码，日常开发集成
保护：✅ 必须通过 Pull Request 合并
禁止：❌ 禁止直接推送
辅助分支（Supporting Branches）
feature/* - 功能开发分支
命名：feature/功能名称，如 feature/user-login
来源：从 develop 创建
目标：合并回 develop
生命周期：功能完成后删除
fix/* - Bug 修复分支
命名：fix/问题描述，如 fix/login-button-bug
来源：从 develop 创建
目标：合并回 develop
生命周期：修复完成后删除
hotfix/* - 紧急修复分支
命名：hotfix/紧急修复描述，如 hotfix/security-patch
来源：从 main 创建
目标：合并回 main 和 develop
生命周期：修复完成后删除
release/* - 发布准备分支
命名：release/版本号，如 release/1.0.0
来源：从 develop 创建
目标：合并回 main 和 develop
生命周期：发布完成后删除
1.2 分支命名规则
✅ 允许的命名：
使用小写字母
使用连字符 - 分隔单词
简洁但描述性
示例：feature/user-authentication、fix/payment-error
❌ 禁止的命名：
使用大写字母
使用下划线或空格
使用个人名称
使用特殊字符
示例：Feature/Login、fix_bug、zhangsan-feature
1.3 分支保护规则
main 分支保护
✅ 必须通过 Pull Request 合并
✅ 至少 1 位团队成员审查通过
✅ 必须通过所有 CI/CD 检查
✅ 禁止直接推送
✅ 禁止强制推送
✅ 禁止删除分支
develop 分支保护
✅ 必须通过 Pull Request 合并
✅ 至少 1 位团队成员审查通过
✅ 必须通过所有 CI/CD 检查
✅ 禁止直接推送
✅ 禁止强制推送
2. 提交信息规范
2.1 提交信息格式
<类型>(<范围>): <简短描述>
<详细描述（可选）>
<相关 Issue（可选）>
版本：v1.0.0
最后更新：2026年
适用范围：所有项目
目录
分支管理规范
提交信息规范
工作流程规范
代码审查规范
命名规范
安全规范
工具与配置
常见场景处理
1. 分支管理规范
1.1 分支类型
主分支（Main Branches）
main / master
用途：生产环境代码
保护：✅ 必须通过 Pull Request 合并
禁止：❌ 禁止直接推送，禁止强制推送
develop
用途：开发环境代码，日常开发集成
保护：✅ 必须通过 Pull Request 合并
禁止：❌ 禁止直接推送
辅助分支（Supporting Branches）
feature/* - 功能开发分支
命名：feature/功能名称，如 feature/user-login
来源：从 develop 创建
目标：合并回 develop
生命周期：功能完成后删除
fix/* - Bug 修复分支
命名：fix/问题描述，如 fix/login-button-bug
来源：从 develop 创建
目标：合并回 develop
生命周期：修复完成后删除
hotfix/* - 紧急修复分支
命名：hotfix/紧急修复描述，如 hotfix/security-patch
来源：从 main 创建
目标：合并回 main 和 develop
生命周期：修复完成后删除
release/* - 发布准备分支
命名：release/版本号，如 release/1.0.0
来源：从 develop 创建
目标：合并回 main 和 develop
生命周期：发布完成后删除
1.2 分支命名规则
✅ 允许的命名：
使用小写字母
使用连字符 - 分隔单词
简洁但描述性
示例：feature/user-authentication、fix/payment-error
❌ 禁止的命名：
使用大写字母
使用下划线或空格
使用个人名称
使用特殊字符
示例：Feature/Login、fix_bug、zhangsan-feature
1.3 分支保护规则
main 分支保护
✅ 必须通过 Pull Request 合并
✅ 至少 1 位团队成员审查通过
✅ 必须通过所有 CI/CD 检查
✅ 禁止直接推送
✅ 禁止强制推送
✅ 禁止删除分支
develop 分支保护
✅ 必须通过 Pull Request 合并
✅ 至少 1 位团队成员审查通过
✅ 必须通过所有 CI/CD 检查
✅ 禁止直接推送
✅ 禁止强制推送
2. 提交信息规范
2.1 提交信息格式
<类型>(<范围>): <简短描述>
<详细描述（可选）>
<相关 Issue（可选）>
5月18
一、什么是Git分支管理？
Git分支管理是指在Git版本控制系统中，通过创建和管理多个分支来组织代码开发流程，支持并行开发、代码隔离和版本控制。
简单说，就像一棵树的主干和分支，master分支是主干，feature分支是枝叶，每个分支都可以独立生长，最后再合并到主干。
其核心作用包括：
• 并行开发：多个功能可以同时开发而不相互干扰。
• 代码隔离：开发分支、测试分支、生产分支相互隔离。
• 版本管理：支持版本回退、热修复和发布管理。
• 团队协作：多人协作时减少代码冲突。
二、分支类型说明
2.1 长期存在分支（核心基础分支）
master 主分支
• 定位：生产环境分支，存放已发布的稳定、可靠版本代码。
• 核心规则：仅用于发布新版本，禁止直接修改或提交新功能。
develop 开发分支
• 定位：日常开发主分支，汇总当前所有正在推进的功能和任务。
• 核心规则：所有新功能开发、改进、优化均从该分支发起，完成后最终合并回此分支。
2.2 临时创建分支（辅助开发/发布分支，完成后删除）
feature 功能分支
• 创建来源：从 develop 分支创建，功能分支的名字，可以采用feature-*的形式命名
• 用途：单独开发某一个新功能（一个功能对应一个分支）
• 流转终点：功能实现、测试完成后，合并回 develop 分支
release 发布分支（不一定用）
• 创建来源：从 develop 分支创建
• 用途：为即将发布的版本做最终准备，仅开展测试、bug修复、文档检查等工作（不新增功能）
• 流转终点：准备完成且测试通过后，同时合并回 master 分支（作为新发布版本）和 develop 分支（同步发布前的修复内容）
hotfix 紧急修复分支
• 创建来源：从 master 分支创建
• 用途：紧急修复生产环境（master 分支对应版本）中出现的问题
• 流转终点：修复完成后，同时合并回 master 分支（更新生产版本）和 develop 分支（同步修复内容，避免后续版本复现问题）
Git分支管理是指在Git版本控制系统中，通过创建和管理多个分支来组织代码开发流程，支持并行开发、代码隔离和版本控制。
简单说，就像一棵树的主干和分支，master分支是主干，feature分支是枝叶，每个分支都可以独立生长，最后再合并到主干。
其核心作用包括：
• 并行开发：多个功能可以同时开发而不相互干扰。
• 代码隔离：开发分支、测试分支、生产分支相互隔离。
• 版本管理：支持版本回退、热修复和发布管理。
• 团队协作：多人协作时减少代码冲突。
二、分支类型说明
2.1 长期存在分支（核心基础分支）
master 主分支
• 定位：生产环境分支，存放已发布的稳定、可靠版本代码。
• 核心规则：仅用于发布新版本，禁止直接修改或提交新功能。
develop 开发分支
• 定位：日常开发主分支，汇总当前所有正在推进的功能和任务。
• 核心规则：所有新功能开发、改进、优化均从该分支发起，完成后最终合并回此分支。
2.2 临时创建分支（辅助开发/发布分支，完成后删除）
feature 功能分支
• 创建来源：从 develop 分支创建，功能分支的名字，可以采用feature-*的形式命名
• 用途：单独开发某一个新功能（一个功能对应一个分支）
• 流转终点：功能实现、测试完成后，合并回 develop 分支
release 发布分支（不一定用）
• 创建来源：从 develop 分支创建
• 用途：为即将发布的版本做最终准备，仅开展测试、bug修复、文档检查等工作（不新增功能）
• 流转终点：准备完成且测试通过后，同时合并回 master 分支（作为新发布版本）和 develop 分支（同步发布前的修复内容）
hotfix 紧急修复分支
• 创建来源：从 master 分支创建
• 用途：紧急修复生产环境（master 分支对应版本）中出现的问题
• 流转终点：修复完成后，同时合并回 master 分支（更新生产版本）和 develop 分支（同步修复内容，避免后续版本复现问题）
