国内 Git 平台工作流配置与 CI/CD 适配：解决…

当国内团队需要在 Gitee、Coding.net、极狐 GitLab、CNB 等平台配置 Git 工作流、CI/CD、PR/MR 模板和国内网络优化时使用。

适用场景

解决思路

1. 核心原则：工作流服务于团队效率，不是为了流程而流程；选适合团队规模的方案，别硬套大厂方案。
2. 按场景选择国内 Git 平台：Gitee 适合开源/小团队；Coding.net 适合中大型团队；极狐 GitLab 适合企业私有化；CNB 适合云原生/Docker 流水线；GitHub 适合国际项目。
3. 平台特性对比：国内访问 Gitee、Coding.net、极狐 GitLab、CNB 快，GitHub 不稳定；免费私有仓库均有；CI/CD 分别用 Gitee Go、Coding CI、内置 GitLab CI、内置 .cnb.yml、GitHub Actions；代码审查分别用 PR、MR、MR、MR、PR；制品库分别有限、完整、完整、完整、Packages。
4. Gitee 设置远程仓库：执行 `git remote add origin https://gitee.com/<org>/<repo>.git`。
5. Gitee 配置 SSH：在 `~/.ssh/config` 写入 Host gitee.com、HostName gitee.com、User git、IdentityFile ~/.ssh/gitee_rsa、PreferredAuthentications publickey。
6. Gitee 与 GitHub 镜像同步：执行 `git remote set-url --add --push origin https://gitee.com/<org>/<repo>.git`，再执行 `git remote set-url --add --push origin https://github.com/<org>/<repo>.git`。
7. Coding.net HTTPS 远程：执行 `git remote add origin https://e.coding.net/<team>/<project>/<repo>.git`。
8. Coding.net SSH 远程：执行 `git remote add origin git@e.coding.net:<team>/<project>/<repo>.git`。
9. 极狐 GitLab 私有化部署远程：执行 `git remote add origin https://jihulab.com/<group>/<repo>.git`。
10. 极狐 GitLab 企业内部部署远程：执行 `git remote add origin https://gitlab.yourcompany.com/<group>/<repo>.git`。
11. CNB 远程：执行 `git remote add origin https://cnb.cool/<org>/<repo>.git`，CNB 仅支持 HTTPS，不提供 SSH 协议。
12. CNB HTTPS 认证：用户名固定为 `cnb`，密码为个人访问令牌（Access Token）；在 CNB 平台 → 个人设置 → 访问令牌 中生成，并执行 `git config credential.helper store`。
13. 工作流选择：小团队（2-8 人）、迭代速度快、有完善自动化测试时选主干开发（Trunk-Based Development）。
14. 主干开发规则：main 始终保持可发布状态；功能分支生命周期不超过 2 天；每天至少合并一次到主干；用 Feature Flag 控制未完成功能的可见性。
15. 主干开发操作：从 main 拉分支 `git checkout -b feat/user-login main`；开发完成后执行 `git fetch origin`、`git rebase origin/main`；提交 PR/MR，合并后删除分支。
16. 工作流选择：中大团队、版本发布节奏固定（如双周迭代）、需要维护多个版本时选 Git Flow。
17. Git Flow 分支职责：main 是生产环境代码，只接受 release 和 hotfix 的合并；develop 是开发主线，功能分支从这里拉出并合回；release/* 从 develop 拉出，只修 bug 不加功能；feat/* 是功能分支；hotfix/* 从 main 拉出，同时合回 main 和 develop。
18. 工作流选择：大多数国内中小团队用简化流程。
19. 简化流程规则：main 受保护，只能通过 PR/MR 合并；dev 对应测试环境并自动部署；功能分支从 dev 拉出并合回 dev；dev 测试通过后合并到 main 进行发布。
20. 分支命名示例：功能分支用 `feat/user-login`、`feat/JIRA-1234-order-refund`；修复分支用 `fix/payment-callback`、`fix/JIRA-5678-null-pointer`；发布分支用 `release/v2.1.0`、`release/2024-03-sprint`；紧急修复用 `hotfix/v2.0.1`、`hotfix/fix-login-crash`；个人分支用 `dev/zhangsan/feat-login`。
21. 分支命名规则：全部小写，用 `-` 连接单词，不用下划线或驼峰。
22. 分支命名规则：前缀明确分支类型：`feat/`、`fix/`、`hotfix/`、`release/`。
23. 分支命名规则：关联任务管理平台的编号（如有），例如 `feat/TAPD-12345-description`。
24. 分支命名规则：长度适中，能看出分支目的即可。
25. 中文 Commit Message 使用约定式提交格式：`<类型>(<范围>): <简要描述>`，空行，正文（可选），空行，脚注（可选）。
26. Commit 类型清单：feat 新增功能（✨）、fix 修复 Bug（🐛）、docs 文档更新（📝）、style 代码格式（💄）、refactor 重构（♻️）、perf 性能优化（⚡）、test 测试相关（✅）、build 构建系统或外部依赖（📦）、ci CI/CD 配置（👷）、chore 其他杂项（🔧）、revert 回滚（⏪）。
27. 好的 commit message 应写：类型范围描述、正文分点说明改动、关联需求如 `TAPD-12345`；修复类写原因、方案、`Closes #567`。
28. 避免 commit message：太笼统如 `update code`、`fix bug`、`修改了一些东西`；没有上下文如 `fix: 修复问题`、`feat: 新增功能`；中英混杂无规范如 `fix：修复了一个bug，因为user login的时候会crash`。
29. Gitee Go 配置：创建 `.gitee/pipelines/pipeline.yml`，设置 `name: 构建与测试`、`displayName`、`triggers.push.branches.include` 为 `main`/`dev`、stages 下 jobs/steps 使用 `npmbuild@1`，inputs 设置 `nodeVersion: 20`、commands `npm ci`、`npm test`。
30. Coding CI 配置：使用 Jenkinsfile 语法，pipeline agent any；stages 包含安装依赖 `npm ci`、单元测试 `npm test`、构建 `npm run build`；部署到测试环境 when branch 'dev' 执行 `./scripts/deploy-staging.sh`；部署到生产环境 when branch 'main' 执行 `./scripts/deploy-production.sh`；post.failure 执行 `./scripts/notify-failure.sh` 通知企业微信/钉钉。
31. 极狐 GitLab CI 配置：创建 `.gitlab-ci.yml`，stages 为 test/build/deploy；variables 设置 `NODE_IMAGE: node:20-alpine`、`NPM_REGISTRY: https://registry.npmmirror.com`；单元测试 stage test、image `$NODE_IMAGE`、script 设置 registry、`npm ci`、`npm test`，coverage 正则 `'/Lines\s*:\s*(\d+\.?\d*)%/'`；构建 stage build、artifacts 为 `dist/`；部署测试环境 only dev environment staging；部署生产环境 only main environment production when manual。
32. CNB 配置：创建 `.cnb.yml`，branch-first 结构，直接指定 Docker 镜像；main push 使用 docker image `node:20`，stages `npm ci`、`npm test`、`npm run build`；main pull_request 使用 docker image `node:20`，stages `npm run lint`、`npm test`。
33. CNB 特点：每个流水线独立指定 Docker 镜像，天然云原生；支持 `push`/`pull_request` 触发；同一事件可并行多条流水线；stages 支持 `- name: xxx` + `script:` 的展开形式，复杂场景见官方文档。
34. GitHub Actions 国内替代对照：触发条件用 Gitee Go triggers、Coding Jenkinsfile triggers、极狐 only/rules、CNB push/pull_request；缓存依赖用 cache step、stash/unstash、cache、见官方文档；制品存储用 artifacts、制品库、artifacts、见官方文档；环境变量用 env、environment、variables、env；密钥管理用环境变量配置、凭据管理、CI/CD Variables、Access Token；手动触发用手动运行、手动触发、when: manual、页面手动运行。
35. 创建 PR/MR 模板：Gitee 路径 `.gitee/PULL_REQUEST_TEMPLATE.md`；Coding/GitLab 路径 `.gitlab/merge_request_templates/default.md`。
36. PR/MR 模板内容包含：变更说明；变更类型 checkbox（feat/fix/refactor/perf/docs/其他）；关联信息（需求/Bug 链接、设计文档）；改动范围；测试情况（单元测试/手动测试/回归测试）；测试方法；影响范围；部署注意事项（数据库迁移/更新配置文件/更新环境变量/无特殊事项）；截图/录屏。
37. Git 配置：设置用户信息 `git config --global user.name "张三"`、`git config --global user.email "zhangsan@company.com"`。
38. Git 配置：commit message 编辑器设为 VS Code：`git config --global core.editor "code --wait"`。
39. Git 配置：解决中文文件名显示为转义字符：`git config --global core.quotepath false`。
40. Git 配置：设置默认分支名：`git config --global init.defaultBranch main`。
41. Git 配置：需要同时使用 GitHub 时设置代理：`git config --global http.https://github.com.proxy socks5://127.0.0.1:7890`。
42. NPM 使用国内镜像：`npm config set registry https://registry.npmmirror.com`。
43. .gitignore 国内项目常见配置包含：IDE（`.idea/`、`.vscode/`、`*.swp`）；依赖（`node_modules/`、`vendor/`）；构建产物（`dist/`、`build/`、`*.exe`）；环境配置（`.env`、`.env.local`、`.env.*.local`）；系统文件（`.DS_Store`、`Thumbs.db`、`desktop.ini`）；国内平台特有（`.coding/`）。
44. 推送代码前检查清单：分支命名符合团队规范；commit message 格式正确，类型和范围准确；关联对应需求/Bug 编号；PR/MR 描述填写完整；CI 流水线通过；已请求相关同事 Review。

适用边界 · 注意事项

• 非国内 Git 平台，或不涉及国内访问、CI/CD、镜像同步适配时不需要使用。
• 用户未显式请求 /chinese-git-workflow 时不要根据上下文自动触发。
• 团队已有更匹配的工作流时，不要为流程而流程或硬套大厂方案。