Git 开发工作流中的约束点

🚀 Git 开发工作流中的约束点优化

在 Git 开发工作流 中，我们可以增加 代码质量、构建约束、分支管理、测试合规性 等多个约束点，以确保代码质量和交付稳定性。以下是 关键约束点 及如何实施的建议：

📌 1. 提交前约束（Pre-Commit & Pre-Push）

📌 目标：在代码提交前，自动检查代码质量，避免低质量代码进入 Git 仓库

✅ 代码风格检查：

前端：ESLint + Prettier（JS/TS）、Stylelint（CSS）
移动端：SwiftLint（iOS）、ktlint（Android）
后端：Checkstyle（Java）、pylint（Python）

✅ 代码格式化（避免提交不规范代码）：

统一格式化 Prettier / clang-format / black

✅ 敏感信息检查（避免 API Key、密码提交到 Git）：

git-secrets / truffleHog 自动扫描

✅ 构建包大小检查（避免超大资源提交）：

size-limit（前端）
apk analyzer（Android）
fastlane xcsize（iOS）

✅ Lint 代码检查：

npx eslint . --fix   # JS/TS
npx stylelint '**/*.css' --fix   # CSS
swiftlint autocorrect   # iOS
ktlint -F   # Android

🔹 工具实现：使用 Husky + lint-staged 配置 Git Hook

npx husky add .husky/pre-commit "npm run lint && npm run format"

📌 2. 提交信息约束（Commit Message）

📌 目标：确保 commit 规范，便于追踪历史 & 生成自动化 Changelog

✅ 使用 Conventional Commits 规范

feat: 新增用户搜索功能
fix: 修复登录按钮点击无响应
chore: 更新 ESLint 规则

✅ 使用 commitlint + husky 限制提交格式

npx husky add .husky/commit-msg "npx commitlint --edit $1"

✅ 自动生成 Changelog

commitizen → 提示填写符合规范的提交信息
standard-version → 自动生成 CHANGELOG.md

📌 3. 分支管理约束

📌 目标：避免主干污染，确保代码变更受控

✅ 推荐 Git 分支策略（Git Flow / Trunk-Based）

main → 线上稳定版本
develop → 开发分支
feature/* → 功能分支
hotfix/* → 线上紧急修复
release/* → 预发布分支

✅ 分支保护（防止误提交 & 直接推送 main）：

main 分支必须开 PR，不能直接 push
PR 需 Review + CI 通过才能合并（required status checks）
feature/* 分支 commit 需 rebase，不允许 merge commit

✅ 自动删除无用分支（PR 合并后自动删除）

git fetch --prune
git branch -d feature/xxx

📌 4. Pull Request 约束

📌 目标：确保 PR 质量，避免错误代码进入主干

✅ 强制 Code Review（GitHub Branch Protection）

至少 1-2 人 代码审查才能合并
PR 超过 500 行代码需拆分（避免大规模变更）
PR 需附带 详细描述（涉及哪些改动 & 影响）

✅ 自动触发 CI/CD 流程（PR 通过 CI 后才能合并）

name: PR Checks
on:
  pull_request:
    branches:
      - main
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run Tests
        run: npm test

✅ 自动运行 sonarqube 代码质量分析

name: Code Quality
on: pull_request
jobs:
  sonar:
    runs-on: ubuntu-latest
    steps:
      - name: SonarCloud Scan
        run: sonar-scanner

📌 5. 代码合并（Merge）约束

📌 目标：确保代码合并后 可回滚、可追踪

✅ 推荐 Merge 策略（避免污染主干）	方式	适用场景
Squash Merge	小型 PR（合并后变 1 条 commit）
Rebase Merge	代码历史保持线性
Merge Commit	需要完整保留 commit 记录

✅ 合并前自动触发 CI/CD（确保测试全部通过）

CI 失败 不能合并 PR
PR 必须 测试覆盖率 ≥ 80% 才能合并

✅ 合并后自动部署（仅对 main 分支生效）

on:
  push:
    branches:
      - main
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to Production
        run: ./deploy.sh

📌 6. 版本 & 发布约束

📌 目标：避免版本混乱，确保每个 Release 可追踪

✅ 版本号采用 Semantic Versioning 规范

MAJOR.MINOR.PATCH（如 1.2.3）
- MAJOR：破坏性变更
- MINOR：新增功能
- PATCH：修复 Bug

✅ 自动生成 Release Notes

npx standard-version

✅ 自动发布到 npm / App Store / Google Play

name: Publish
on:
  push:
    tags:
      - "v*.*.*"
jobs:
  publish:
    steps:
      - name: Publish to npm
        run: npm publish

💡 7. 关键 Git 约束点总结

阶段	约束点	实现方式
提交前	代码风格、构建大小、敏感信息	`Husky` / `ESLint` / `git-secrets`
Commit	规范化提交信息	`commitlint` / `commitizen`
分支管理	受控 Git Flow	`GitHub Branch Protection`
Pull Request	强制 Code Review、CI/CD	`GitHub Actions` / `SonarQube`
代码合并	确保 CI 通过，自动测试	`GitHub Actions`
版本管理	语义化版本，自动发布	`standard-version` / `npm publish`

🎯 结论

✅ 自动化代码检查（Lint、构建大小、敏感信息检测）
✅ 严格的分支管理（PR 保护、强制 Code Review）
✅ CI/CD 约束（测试 & 质量检查通过才能合并）
✅ 自动版本管理（语义化版本、自动 Release Notes）

晴耕雨读

Git 开发工作流中的约束点