在 DevOps 实践中，分支策略直接决定了团队的发布节奏、代码质量和协作效率。选择错误的工作流可能导致合并地狱、发布延期甚至线上事故。本文系统梳理七种主流 Git 工作流，从经典 Git Flow 到现代 Trunk Based Development，再到 Monorepo 工程化方案，帮助你为团队找到最合适的分支策略。
一、Git Flow：经典但沉重的分支模型
Git Flow 由 Vincent Driessen 于 2010 年提出，它定义了一套严格的分支命名规则和生命周期管理方案，适合需要长期维护多个版本的软件项目。
1.1 核心分支结构
Git Flow 包含两类长期分支和三类临时分支：
- master：仅保存生产就绪的代码，每个 commit 对应一个正式发布版本
- develop：日常开发的集成分支，所有功能在此汇合
- feature/*：从 develop 切出，用于开发新功能
- release/*：从 develop 切出，用于版本发布前的测试与修复
- hotfix/*：从 master 切出，用于紧急修复线上问题
# 初始化 Git Flow（需安装 git-flow 扩展）
git flow init -d
# 创建并切换到一个新功能分支
git flow feature start user-authentication
# 完成功能开发，合并回 develop
git flow feature finish user-authentication
# 开始一个发布流程
git flow release start 2.1.0
# 发布完成后，同时合并到 master 和 develop
git flow release finish 2.1.0
1.2 完整的 Git Flow 发布流程
# 1. 开发人员创建功能分支
git checkout develop
git pull origin develop
git checkout -b feature/payment-gateway
# 2. 开发过程中进行多次提交
git add .
git commit -m "feat(payment): 集成 Stripe 支付接口"
git commit -m "feat(payment): 添加支付回调重试机制"
# 3. 功能完成后向 develop 发起合并请求
git checkout develop
git merge --no-ff feature/payment-gateway
git branch -d feature/payment-gateway
# 4. 准备发布时创建 release 分支
git checkout -b release/2.1.0 develop
# 5. 在 release 分支上进行最后的 Bug 修复
#（不允许添加新功能，确保发布稳定性）
git commit -m "fix(release): 修复订单金额精度问题"
# 6. 完成发布，合并到 master 和 develop
git checkout master
git merge --no-ff release/2.1.0
git tag -a v2.1.0 -m "Release version 2.1.0"
git checkout develop
git merge --no-ff release/2.1.0
git branch -d release/2.1.0
1.3 Git Flow 的适用场景与限制
Git Flow 的强项在于版本隔离和发布控制，特别适合：
- 需要同时维护多个大版本的企业级软件
- 发布周期较长（数周甚至数月）的传统项目
- 有着严格 QA 流程和回归测试要求的系统
但 Git Flow 也存在明显弊端：
- 分支模型复杂，新成员学习成本高
- 长期的功能分支容易导致巨大的合并冲突
- 不适合持续交付（CD）场景，发布周期难以缩短
二、GitHub Flow：极简主义的 Web 开发首选
GitHub Flow 是为持续部署设计的轻量级工作流，由 GitHub 官方推荐，特别适合以 Web 应用为主的团队。
2.1 GitHub Flow 的核心原则
GitHub Flow 的核心思想极其简单：master 分支始终可部署，任何改动都通过短生命周期的功能分支和 Pull Request（PR）完成。
# 1. 从 master 创建功能分支
git checkout master
git pull origin master
git checkout -b feature/add-dark-mode
# 2. 开发并提交
git add .
git commit -m "feat(ui): 实现深色模式切换功能"
git push origin feature/add-dark-mode
# 3. 在 GitHub 上创建 Pull Request，请求合并到 master
# 4. 代码审查通过后，直接合并（通常使用 Squash Merge 保持历史整洁）
git checkout master
git pull origin master
# 5. 部署到生产环境（通常由 CI/CD 自动触发）
2.2 配合 CI/CD 的完整流水线
在 GitHub Flow 中，每个 PR 都应该触发完整的自动化验证：
# .github/workflows/ci.yml
name: Continuous Integration
on:
push:
branches: [master]
pull_request:
branches: [master]
jobs:
build-and-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: "20"
cache: "npm"
- name: Install dependencies
run: npm ci
- name: Run linter
run: npm run lint
- name: Run type checking
run: npm run type-check
- name: Run tests
run: npm run test:ci
- name: Build application
run: npm run build
- name: Upload coverage
uses: codecov/codecov-action@v3
with:
files: ./coverage/lcov.info
2.3 GitHub Flow 的最佳实践
# 使用 rebase 保持分支整洁，避免无关的 merge commit
git checkout feature/add-dark-mode
git fetch origin
git rebase origin/master
# 若存在冲突，解决后强制推送（团队的共享分支策略需提前约定）
git push --force-with-lease origin feature/add-dark-mode
# 合并前确保本地 master 已更新
git checkout master
git pull origin master
GitHub Flow 适用于：
- 采用持续部署的 Web 和 SaaS 产品
- 发布频率高（一天内多次发布）的团队
- 团队规模较小，沟通成本低的项目
三、GitLab Flow：带环境分支的实用方案
GitLab Flow 结合了 Git Flow 的环境管理和 GitHub Flow 的简洁性，通过引入环境分支（如 staging、production）来跟踪不同环境的代码状态。
3.1 基于环境分支的 GitLab Flow
# 项目分支结构
# master（主开发分支）
# pre-production（预发布环境）
# production（生产环境）
# 1. 功能开发在 master 上进行
git checkout master
git checkout -b feature/api-rate-limiting
# 2. 开发完成，合并到 master
git checkout master
git merge feature/api-rate-limiting
# 3. 当需要部署到预发布环境时，合并到 pre-production
git checkout pre-production
git merge master
git tag -a v1.3.0-rc.1 -m "Release candidate 1.3.0"
git push origin pre-production --follow-tags
# 4. 预发布环境验证通过后，合并到 production
git checkout production
git merge pre-production
git tag -a v1.3.0 -m "Release version 1.3.0"
git push origin production --follow-tags
3.2 带发布分支的 GitLab Flow（适合版本化软件）
对于需要维护多个版本的客户端软件，GitLab Flow 也支持 release 分支：
# 创建维护分支并打上版本标签
git checkout -b 2-3-stable master
# 2-3-stable 分支只接受 Bug 修复
git checkout -b fix/memory-leak-2-3 2-3-stable
# ... 修复内存泄漏 ...
git checkout 2-3-stable
git merge fix/memory-leak-2-3
git tag -a v2.3.1 -m "Patch release 2.3.1"
# 同时将修复 cherry-pick 到 master，避免回归
git checkout master
git cherry-pick <fix-commit-hash>
3.3 GitLab CI 集成示例
# .gitlab-ci.yml
stages:
- test
- build
- deploy
variables:
DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG
test:
stage: test
image: node:20-alpine
script:
- npm ci
- npm run lint
- npm run test -- --coverage
coverage: '/All files[^|]*\|[^|]*\s+([\d\.]+)/'
artifacts:
paths:
- coverage/
expire_in: 1 week
deploy_staging:
stage: deploy
script:
- docker build -t $DOCKER_IMAGE .
- docker push $DOCKER_IMAGE
- kubectl set image deployment/app app=$DOCKER_IMAGE -n staging
environment:
name: staging
url: https://staging.example.com
only:
- pre-production
deploy_production:
stage: deploy
script:
- docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_TAG .
- docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_TAG
- kubectl set image deployment/app app=$CI_REGISTRY_IMAGE:$CI_COMMIT_TAG -n production
environment:
name: production
url: https://www.example.com
only:
- tags
when: manual
四、Trunk Based Development：主干开发的现代实践
Trunk Based Development（TBD）是一种所有开发者直接在主干（trunk/main/master）上进行开发的工作流，辅以短期功能分支（通常不超过一天）和特性开关（Feature Flags）。
4.1 TBD 的核心理念
TBD 的目标是最大限度减少分支生命周期，防止集成地狱：
- 主干唯一：所有代码最终都必须进入主干
- 短分支：功能分支存活时间以小时计，最长不超过一天
- 特性开关：未完成的代码通过 Feature Flag 隐藏，但不阻塞集成
- 自动化测试：闸门式的 CI 流水线确保主干始终健康
# TBD 的典型日工作流程
# 8:00 更新主干
git checkout main
git pull origin main
# 8:05 创建功能分支（预计今天完成）
git checkout -b feat/search-suggestions
# 12:00 开发完成，本地测试通过，发起 PR
git add .
git commit -m "feat(search): 实现实时搜索建议"
git push origin feat/search-suggestions
# --> 创建 PR，等待 CI 通过和同事审查
# 14:00 PR 合并后，立即使用特性开关控制发布
# 代码已在主干，但功能默认关闭
4.2 特性开关（Feature Flags）的实现
特性开关是 TBD 的关键技术，确保未完成的功能不会暴露给最终用户：
// src/features/search-suggestions/index.ts
import { useFlag } from "@/lib/feature-flags";
export function SearchSuggestions({ query }: { query: string }) {
const isEnabled = useFlag("search-suggestions-v2");
if (!isEnabled) {
// 回退到旧版搜索或完全不显示
return <LegacySearch query={query} />;
}
return <NewSearchSuggestions query={query} />;
}
// 特性开关服务（可对接 LaunchDarkly、Unleash 或自研）
// src/lib/feature-flags.ts
interface FeatureFlagConfig {
[key: string]: boolean;
}
export class FeatureFlagManager {
private flags: FeatureFlagConfig = {};
async refresh(userId?: string): Promise<void> {
// 从服务端拉取当前用户的特性开关配置
const response = await fetch(`/api/feature-flags?userId=${userId || ""}`);
this.flags = await response.json();
}
isEnabled(flagName: string): boolean {
return !!this.flags[flagName];
}
}
4.3 分支 by 抽象（Branch by Abstraction）
对于大规模重构，TBD 推荐使用"分支 by 抽象"来避免长期分支：
// 重构前：直接依赖旧实现
// import { LegacyPaymentService } from "./legacy-payment";
// 重构时：引入抽象层，允许新旧实现共存
interface PaymentService {
process(order: Order): Promise<PaymentResult>;
}
class LegacyPaymentAdapter implements PaymentService {
async process(order: Order): Promise<PaymentResult> {
// 调用旧版实现
return legacyProcess(order);
}
}
class NewPaymentAdapter implements PaymentService {
async process(order: Order): Promise<PaymentResult> {
// 新版实现
return newProcess(order);
}
}
// 工厂根据特性开关返回不同实现
function createPaymentService(): PaymentService {
const useNewPayment = featureFlags.isEnabled("new-payment-service");
return useNewPayment ? new NewPaymentAdapter() : new LegacyPaymentAdapter();
}
4.4 TBD 的 CI 闸门配置
#!/bin/bash
# ci-gate.sh - 主干提交的严格检查脚本
set -euo pipefail
echo "=== Running Trunk Based Development CI Gate ==="
# 1. 快速单元测试（< 2 分钟）
echo "Running unit tests..."
npm run test:unit -- --maxWorkers=4
# 2. 静态代码分析
echo "Running static analysis..."
npm run lint
npm run type-check
npx prettier --check "src/**/*.{ts,tsx}"
# 3. 安全检查
echo "Running security audit..."
npm audit --audit-level=moderate
npx trivy filesystem --exit-code 1 .
# 4. 构建验证
echo "Running production build..."
npm run build
# 5. 集成测试（可异步执行，不阻塞合并）
echo "Triggering integration tests..."
curl -X POST \
-H "Authorization: Bearer $CI_TOKEN" \
-d '{"pipeline": "integration-tests", "ref": "'"$CI_COMMIT_SHA"'"}' \
$CI_API_URL/trigger
echo "=== CI Gate Passed ==="
五、Monorepo 工作流：Turborepo、Nx 与 Rush
当团队采用 Monorepo（单一代码仓库）管理多个应用和共享库时，传统 Git 工作流需要配合专用工具链来应对规模挑战。
5.1 Turborepo 工作流与流水线优化
Turborepo 通过智能任务调度和远程缓存大幅加速 Monorepo 构建：
// turbo.json
{
"$schema": "https://turbo.build/schema.json",
"globalDependencies": ["**/.env.*local"],
"pipeline": {
"build": {
"dependsOn": ["^build"],
"outputs": [".next/**", "!.next/cache/**", "dist/**"]
},
"test": {
"dependsOn": ["build"],
"inputs": ["src/**/*.tsx", "src/**/*.ts", "test/**/*.ts"]
}, "lint": {},
"type-check": {
"dependsOn": ["^build"]
},
"dev": {
"cache": false,
"persistent": true
}
}
}
# 在 Monorepo 中开发功能，利用 Turborepo 增量构建
# 1. 安装依赖（根目录）
pnpm install
# 2. 只构建受影响的项目及其依赖
npx turbo run build --filter=...@myorg/web-app
# 3. 只运行变化的包的测试
npx turbo run test --filter=[HEAD~1]
# 4. 开发时启动相关服务的 watch 模式
npx turbo run dev --filter=@myorg/web-app...
5.2 Nx 的分支策略与依赖图
Nx 提供了强大的依赖图分析和 affected 命令，帮助你在 Monorepo 中精确知道哪些项目需要重新构建或测试：
# 查看整个 Monorepo 的依赖图
npx nx graph
# 基于上次合并基础，只受影响的项目的测试
npx nx affected -t test --base=origin/main --head=HEAD
# 只构建变更的应用及其上游依赖
npx nx affected -t build --base=origin/main
# 在 CI 中使用并行执行
npx nx run-many -t build test lint -p @myorg/api @myorg/web --parallel=3
// nx.json - 配置项目间隐式依赖和缓存
{
"extends": "nx/presets/core.json",
"npmScope": "myorg",
"tasksRunnerOptions": {
"default": {
"runner": "nx-cloud",
"options": {
"cacheableOperations": ["build", "test", "lint", "e2e"],
"accessToken": "YOUR_NX_CLOUD_TOKEN"
}
}
},
"targetDefaults": {
"build": {
"dependsOn": ["^build"],
"inputs": ["production", "^production"]
}
},
"namedInputs": {
"default": ["{projectRoot}/**/*", "sharedGlobals"],
"production": [
"default",
"!{projectRoot}/**/?(*.)+(spec|test).[jt]s?(x)?(.snap)",
"!{projectRoot}/tsconfig.spec.json"
]
}
}
5.3 Rush Stack 的企业级 Monorepo 方案
Rush 由微软出品，更适合超大型 Monorepo 和企业级依赖管理：
// rush.json
{
"$schema": "https://developer.microsoft.com/json-schemas/rush/v5/rush.schema.json",
"rushVersion": "5.112.0",
"pnpmVersion": "8.14.0",
"nodeSupportedVersionRange": ">=18.0.0 <21.0.0",
"projects": [
{
"packageName": "@myorg/logger",
"projectFolder": "libraries/logger"
},
{
"packageName": "@myorg/api-client",
"projectFolder": "libraries/api-client"
},
{
"packageName": "@myorg/admin-dashboard",
"projectFolder": "apps/admin-dashboard"
},
{
"packageName": "@myorg/customer-portal",
"projectFolder": "apps/customer-portal"
}
]
}
# Rush 常用工作流命令
# 安装所有依赖并建立符号链接
rush update
# 构建所有项目（自动处理拓扑顺序）
rush rebuild
# 只构建变更的项目
rush build
# 运行所有项目的测试
rush test
# 提交前检查（确保 change log 已记录）
rush change -v
# 批量发布（基于 change files）
rush publish --apply --publish --include-all
# common/config/rush/.pnpmfile.cjs - 处理依赖冲突
module.exports = {
hooks: {
readPackage(pkg, context) {
// 强制统一 React 版本
if (pkg.dependencies && pkg.dependencies.react) {
pkg.dependencies.react = "^18.2.0";
}
if (pkg.dependencies && pkg.dependencies["react-dom"]) {
pkg.dependencies["react-dom"] = "^18.2.0";
}
return pkg;
}
}
};
六、Commit Message 规范与自动化
统一的提交信息规范不仅能生成清晰的变更日志（Changelog），还能与 CI/CD 流水线深度集成，实现自动化版本管理和发布。
6.1 Conventional Commits 规范详解
Conventional Commits 是目前最广泛采用的提交信息规范：
<type>(<scope>): <subject>
<body>
<footer>
常见 type 分类：
- feat: 新功能
- fix: Bug 修复
- docs: 文档更新
- style: 代码格式调整（不影响功能）
- refactor: 重构（既不修复 Bug 也不添加功能）
- perf: 性能优化
- test: 测试相关
- chore: 构建过程或辅助工具的变更
- ci: CI/CD 配置变更
- build: 影响构建系统或外部依赖的变更
- revert: 回滚之前的提交
# 符合规范的提交示例
git commit -m "feat(auth): 集成 OIDC 单点登录"
git commit -m "fix(api): 修复分页参数越界导致的 500 错误
当 pageSize 超过 1000 时，数据库查询会触发内存溢出。
现增加最大分页限制为 500，超出时自动降级。
Closes #342"
git commit -m "refactor(db): 将用户查询迁移到 Prisma ORM
BREAKING CHANGE: 移除了原生 SQL 接口，所有查询必须通过 Prisma Client。
迁移文档参见 /docs/migration/prisma-v3.md"
6.2 Commitlint 与 Husky 集成
通过 Husky 和 Commitlint 强制团队成员遵守提交规范：
// commitlint.config.js
module.exports = {
extends: ["@commitlint/config-conventional"],
rules: {
"type-enum": [
2,
"always",
[
"feat",
"fix",
"docs",
"style",
"refactor",
"perf",
"test",
"chore",
"ci",
"build",
"revert"
]
],
"scope-enum": [
2,
"always",
["api", "web", "db", "auth", "ui", "ci", "deps"]
],
"subject-case": [2, "always", "lower-case"],
"subject-max-length": [2, "always", 72],
"body-max-line-length": [2, "always", 100]
}
};
// package.json 中的 Husky 配置
{
"devDependencies": {
"husky": "^9.0.0",
"@commitlint/cli": "^19.0.0",
"@commitlint/config-conventional": "^19.0.0"
},
"scripts": {
"prepare": "husky",
"commitlint": "commitlint --edit"
}
}
# 初始化 Husky 并添加 commit-msg 钩子
npx husky init
echo 'npx --no -- commitlint --edit ${1}' > .husky/commit-msg
# 也可添加 pre-commit 钩子运行 lint 和格式化
echo 'npx lint-staged' > .husky/pre-commit
6.3 自动化版本管理与 Changelog 生成
配合 standard-version 或 semantic-release，可以从规范的提交信息自动生成版本号和变更日志：
# standard-version 自动计算版本并生成 CHANGELOG
npx standard-version
# 仅生成 Patch 版本（fix 类型提交）
npx standard-version --release-as patch
# 生成 Minor 版本（feat 类型提交）
npx standard-version --release-as minor
# 生成 Major 版本（BREAKING CHANGE）
npx standard-version --release-as major
# 推送生成的 tag 和 changelog
npx standard-version && git push --follow-tags origin main
# .versionrc.js - standard-version 配置
module.exports = {
types: [
{ type: "feat", section: "Features" },
{ type: "fix", section: "Bug Fixes" },
{ type: "perf", section: "Performance Improvements" },
{ type: "revert", section: "Reverts" },
{ type: "docs", section: "Documentation", hidden: false },
{ type: "style", section: "Styles", hidden: true },
{ type: "refactor", section: "Code Refactoring", hidden: false },
{ type: "test", section: "Tests", hidden: true },
{ type: "chore", section: "Chores", hidden: true },
{ type: "ci", section: "CI/CD", hidden: true }
],
commitUrlFormat:
"https://github.com/myorg/myrepo/commit/{{hash}}",
compareUrlFormat:
"https://github.com/myorg/myrepo/compare/{{previousTag}}...{{currentTag}}"
};
七、代码审查（Code Review）自动化
高质量的代码审查是保障代码质量的关键防线。现代 DevOps 实践将大量审查工作前置到提交阶段，通过自动化工具减少人工审查负担。
7.1 自动化代码质量检查
# .github/workflows/code-review.yml
name: Automated Code Review
on:
pull_request:
types: [opened, synchronize]
jobs:
automated-review:
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: write
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Setup environment
uses: actions/setup-node@v4
with:
node-version: "20"
- name: Install dependencies
run: npm ci
- name: Run ESLint with reviewdog
uses: reviewdog/action-eslint@v1
with:
reporter: github-pr-review
eslint_flags: "src/"
- name: Run Markdown lint
uses: reviewdog/action-markdownlint@v0
with:
reporter: github-pr-review
- name: Check for secrets
uses: trufflesecurity/trufflehog@main
with:
path: ./
base: ${{ github.event.repository.default_branch }}
head: HEAD
extra_args: --debug --only-verified
- name: Run SonarQube scan
uses: SonarSource/sonarqube-scan-action@master
env:
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
7.2 Danger.js 自动化 PR 检查
Danger 可以在 PR 中自动发布检查结果，提醒开发者处理常见问题：
// dangerfile.ts
import { danger, fail, warn, message } from "danger";
// 检查 PR 描述是否填写
if (!danger.github.pr.body || danger.github.pr.body.length < 50) {
fail("PR 描述过于简短，请补充变更背景和测试说明。");
}
// 检查是否包含测试文件
const hasTests = danger.git.modified_files.some(
(f) => f.includes(".test.") || f.includes(".spec.")
);
if (!hasTests && danger.github.pr.additions > 100) {
warn("本次改动超过 100 行但未发现测试文件，请补充单元测试。");
}
// 检查敏感文件变更
const sensitiveFiles = [".env", "docker-compose.yml", "Dockerfile"];
const touchedSensitive = danger.git.modified_files.filter((f) =>
sensitiveFiles.some((s) => f.includes(s))
);
if (touchedSensitive.length > 0) {
warn(`以下敏感文件发生变更，请确认配置安全：${touchedSensitive.join(", ")}`);
}
// 检查包体积变化
const packageJsonChanges = danger.git.modified_files.filter(
(f) => f === "package.json" || f === "package-lock.json"
);
if (packageJsonChanges.length > 0) {
message("检测到依赖变更，CI 将自动分析包体积影响。");
}
// 鼓励小步提交
const bigPRThreshold = 500;
if (danger.github.pr.additions + danger.github.pr.deletions > bigPRThreshold) {
warn(`PR 变更量过大（${danger.github.pr.additions + danger.github.pr.deletions} 行），建议拆分提交。`);
}
# 在 CI 中运行 Danger
npx danger ci --failOnErrors
7.3 PR 模板与审查清单
<!-- .github/pull_request_template.md -->
## 变更说明
<!-- 描述本次 PR 的目的和背景 -->
## 类型
- [ ] feat: 新功能
- [ ] fix: Bug 修复
- [ ] docs: 文档更新
- [ ] refactor: 重构
- [ ] perf: 性能优化
- [ ] test: 测试更新
- [ ] chore: 构建/工具变更
## 审查清单
- [ ] 代码符合项目编码规范
- [ ] 已添加/更新单元测试
- [ ] 已补充必要的注释和文档
- [ ] 已在本地验证功能正常
- [ ] 敏感信息（密码、Token）未提交到仓库
- [ ] 变更对性能无显著负面影响
主流 Git 工作流对比
| 维度 | Git Flow | GitHub Flow | GitLab Flow | Trunk Based | Monorepo 工具 |
|---|---|---|---|---|---|
| 分支复杂度 | 高（5 类分支） | 极低（2 类） | 中（环境分支） | 极低（主干为主） | 中（配合工具链） |
| 发布频率 | 周/月级 | 日/小时级 | 周级 | 小时/分钟级 | 依项目而异 |
| 适合团队规模 | 中大 | 小中 | 中大 | 任何规模 | 大/超大型 |
| 学习成本 | 高 | 极低 | 低 | 中 | 高 |
| 回滚能力 | 强（版本标签） | 依赖 CI/CD | 强（环境标签） | 依赖特性开关 | 依赖包版本 |
| 持续交付支持 | 弱 | 强 | 中 | 极强 | 中强 |
| 版本维护 | 优秀（多版本并行） | 不需要 | 良好 | 困难 | 良好 |
| Monorepo 支持 | 手动管理 | 手动管理 | 手动管理 | 手动管理 | 原生支持 |
常见问题 FAQ
Q1: 小团队应该选择哪种 Git 工作流？
A: 对于 5 人以下的小团队，首推 GitHub Flow 或简化版 GitLab Flow。这两种工作流几乎没有学习成本，配合自动化 CI/CD 可以实现每日多次发布。如果团队使用 GitHub，GitHub Flow 是最自然的选择；如果需要区分 staging 和 production 环境，GitLab Flow 的环境分支会更实用。除非你们的项目需要同时维护多个大版本（如 SaaS 产品 + 私有化部署），否则不建议使用 Git Flow。
Q2: Trunk Based Development 是否意味着不再使用功能分支？
A: 不是。TBD 允许使用短生命周期的功能分支，但强调分支存活时间不应超过一天。如果某项功能确实需要更长时间开发，应该采用**特性开关（Feature Flags）**将未完成代码隐藏在主干中，而不是让分支长期游离在外。真正的 TBD 极端实践是所有开发者直接向主干提交（如 Google 的部分团队），但这需要极强的自动化测试文化和代码审查机制作为支撑。
Q3: Monorepo 下如何管理跨项目的依赖版本冲突？
A: 推荐使用 Rush 或 Nx 这类原生支持 Monorepo 的工具。Rush 通过严格的版本策略（如 autoinstaller 和 common-versions.json）强制统一依赖版本；Nx 和 Turborepo 则通过依赖图分析精确计算需要构建的项目。在 Rush 中可以配置 ensureConsistentVersions 来强制所有项目使用相同的依赖版本，避免"依赖地狱"。对于必须使用不同版本的场景，可以通过 Rush 的 preferredVersions 进行集中管理。
Q4: 如何在已有项目中迁移到 Conventional Commits？
A: 迁移可以分三步走：
- 安装基础设施：添加
husky+@commitlint/config-conventional，在commit-msg钩子中启用校验。 - 团队培训：在 1-2 个 Sprint 内不强制拦截，通过 CI 告警提醒开发者适应新规范。
- 强制执行：团队适应后开启严格校验，同时引入
standard-version或semantic-release自动生成 Changelog。
对于历史提交，无需重写。可以从启用规范的那个 commit 开始生成新的 CHANGELOG。如果需要历史兼容，可以使用 conventional-changelog-cli 的 --tag-prefix 参数从指定版本开始生成。
总结
Git 工作流没有银弹。选择工作流时应综合考虑团队规模、发布频率、技术成熟度和产品形态：
- 传统软件/多版本维护：Git Flow 提供最强的版本控制能力
- Web 应用/持续部署：GitHub Flow 或 Trunk Based Development 最大化发布效率
- 需要环境隔离：GitLab Flow 的分阶段环境管理更稳妥
- 大型 Monorepo：配合 Turborepo、Nx 或 Rush 实现规模化开发
无论选择哪种工作流，都应建立统一的提交规范、自动化的 CI 闸门和高效的代码审查机制。这三者是保障代码质量的基石，与工作流本身同样重要。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。