概述
国内团队使用 Git 时常遇到几类问题：GitHub 访问不稳定；CI/CD 方案照搬国外水土不服；commit message 中英混杂、缺少规范。本技能提供一套适配国内平台与团队习惯的 Git 工作流参考。
核心原则：工作流服务于团队效率，不是为了流程而流程。应选择适合团队规模的方案，不必硬套大厂做法。
调用方式
仅在用户显式输入 /chinese-git-workflow 时调用，不要根据上下文自动触发。
国内 Git 平台适配
提供 Gitee、Coding.net、极狐 GitLab、CNB、GitHub 的特性对照，涵盖国内访问速度、免费私有仓库、CI/CD 方案、代码审查方式（PR/MR）、制品库与适合场景。例如：Gitee 适合开源/小团队，Coding.net 适合中大型团队，极狐 GitLab 适合企业私有化，CNB 适合云原生 / Docker 流水线，GitHub 适合国际项目。
各平台配置示例
Gitee：
git remote add origin https://gitee.com/<org>/<repo>.git
SSH 配置写入 ~/.ssh/config，指定 Host gitee.com、User git、IdentityFile 与 PreferredAuthentications publickey。镜像同步可用 git remote set-url --add --push origin 依次添加 Gitee 与 GitHub 地址。
Coding.net：
git remote add origin https://e.coding.net/<team>/<project>/<repo>.git
git remote add origin git@e.coding.net:<team>/<project>/<repo>.git
极狐 GitLab：
git remote add origin https://jihulab.com/<group>/<repo>.git
git remote add origin https://gitlab.yourcompany.com/<group>/<repo>.git
CNB（仅支持 HTTPS，不提供 SSH 协议）：
git remote add origin https://cnb.cool/<org>/<repo>.git
git config credential.helper store
HTTPS 认证用户名固定为 cnb，密码为个人访问令牌（Access Token），在 CNB 平台 → 个人设置 → 访问令牌中生成。
工作流选择
方案一：主干开发（Trunk-Based Development）
适合小团队（2-8 人）、迭代速度快、有完善的自动化测试。规则：主干（main）始终保持可发布状态；功能分支生命周期不超过 2 天；每天至少合并一次到主干；用 Feature Flag 控制未完成功能的可见性。示意流程包含从 main 拉分支、rebase 到最新 main、提交 PR/MR 后合并并删除分支。
方案二：Git Flow（经典分支模型）
适合中大团队、版本发布节奏固定（如双周迭代）、需要维护多个版本。分支说明：main 为生产环境代码，只接受 release 和 hotfix 合并；develop 为开发主线；release/* 从 develop 拉出、只修 bug 不加功能；feat/* 为功能分支；hotfix/* 从 main 拉出并同时合回 main 和 develop。
方案三：国内团队常用简化流程
适合大多数国内中小团队。规则：main 受保护，只能通过 PR/MR 合并；dev 对应测试环境并自动部署；功能分支从 dev 拉出、合回 dev；dev 测试通过后合并到 main 进行发布。
分支命名规范
常用前缀包括 feat/（新功能）、fix/（Bug 修复）、release/（版本发布）、hotfix/（紧急修复）、dev/（个人分支），可关联任务编号（如 feat/JIRA-1234-order-refund 或 feat/TAPD-12345-description）。命名规则：全部小写、用 - 连接单词、前缀明确分支类型、关联任务管理平台编号、长度适中。
中文 Commit Message 规范
采用约定式提交（Conventional Commits）中文版结构：<类型>(<范围>): <简要描述>，后接可选正文与脚注，各段之间空行分隔。
类型清单：feat（新增功能）、fix（修复 Bug）、docs（文档更新）、style（代码格式）、refactor（重构）、perf（性能优化）、test（测试相关）、build（构建系统或外部依赖）、ci（CI/CD 配置）、chore（其他杂项）、revert（回滚），并可选用对应 emoji。
资料给出了正面与反面示例。好的示例包含背景原因与方案说明（如升级 SDK 版本、更新 Associated Domains 配置），并关联需求编号或 Closes #567；不好的示例包括 update code、fix bug、修改了一些东西等笼统描述，以及中英混杂无规范的写法。
CI/CD 平台适配
提供四个平台的配置片段：
- Gitee Go：
.gitee/pipelines/pipeline.yml，含 triggers（push 分支 main/dev）与 stages/jobs/steps 结构，使用 npmbuild@1 步骤。 - Coding CI：Jenkinsfile 语法，包含安装依赖、单元测试、构建、部署测试环境（dev 分支）、部署生产环境（main 分支）等 stage，post failure 可做企业微信/钉钉通知。
- 极狐 GitLab CI：
.gitlab-ci.yml，定义 test/build/deploy 三阶段，使用 node:20-alpine 镜像与国内 NPM 镜像 registry.npmmirror.com，构建产出 dist/ 制品，生产部署 when: manual 手动触发。 - CNB：
.cnb.yml，采用 branch-first 结构，直接指定 Docker 镜像（如 node:20）运行 stages，支持 push / pull_request 触发，同一事件可并行多条流水线；也支持- name: xxx + script:的展开形式，复杂场景见官方文档。
另附 GitHub Actions 功能在国内平台的对照表，涵盖触发条件、缓存依赖、制品存储、环境变量、密钥管理、手动触发等项目；部分项标注“见官方文档”。
PR/MR 描述模板
中文模板文件位置：Gitee 使用 .gitee/PULL_REQUEST_TEMPLATE.md；Coding / GitLab 使用 .gitlab/merge_request_templates/default.md。模板包含变更说明、变更类型勾选（feat/fix/refactor/perf/docs/其他）、关联信息、改动范围、测试情况、测试方法、影响范围、部署注意事项、截图/录屏等小节。
常用 Git 配置与 .gitignore
国内环境优化配置包括：设置用户信息、commit 编辑器设为 VS Code、core.quotepath false 解决中文文件名转义、init.defaultBranch main、GitHub 代理设置、NPM 使用国内镜像。
.gitignore 常见配置覆盖 IDE（.idea/、.vscode/、.swp）、依赖（node_modules/、vendor/）、构建产物（dist/、build/、.exe）、环境配置（.env 系列）、系统文件（.DS_Store、Thumbs.db、desktop.ini）以及国内平台特有目录（.coding/）。
检查清单
推送代码前确认：分支命名符合团队规范；commit message 格式正确、类型和范围准确；关联了对应需求/Bug 编号；PR/MR 描述填写完整；CI 流水线通过；已请求相关同事 Review。
限制
本技能仅在用户显式调用时生效，不根据上下文自动触发。资料未提供技能本身的安装命令、编程语言实现细节与收费信息。