2025-10-25发表2025-10-29更新Git22 分钟读完 (大约3312个字)0次访问

Git Flow 从入门到精通

💡 一句话理解 Git Flow

Git Flow 是一种”分支管理策略”，用来规范：

谁改哪条分支
哪些分支能合并
什么时候发布版本

🧭 Git Flow 核心分支模型

分支	作用	谁可以动
`main`	永远保持”可发布”的生产版本	维护者
`develop`	日常开发主分支，整合所有 feature	核心开发者
`feature/*`	新功能分支，基于 develop 创建	所有贡献者
`release/*`	准备发布的候选版本，来自 develop	维护者
`hotfix/*`	紧急修复生产问题，来自 main	维护者

🔧 执行规范建议（开源项目可执行版）

1️⃣ 新功能开发

创建 Feature 分支

从 develop 创建分支：

# 1. 切换到 develop 分支
git checkout develop

# 2. 拉取最新代码
git pull origin develop

# 3. 创建新的功能分支
git checkout -b feature/user-authentication

# 4. 查看当前分支
git branch

分支命名规范

类型	命名格式	示例
新功能	`feature/功能名称`	`feature/user-login`
Bug 修复	`feature/fix-问题描述`	`feature/fix-memory-leak`
重构	`feature/refactor-模块名`	`feature/refactor-api-client`
文档	`feature/docs-说明`	`feature/docs-api-reference`

开发与提交

# 1. 进行开发工作
# ... 编写代码 ...

# 2. 查看修改状态
git status

# 3. 添加修改到暂存区
git add .

# 4. 提交修改（遵循 Conventional Commits）
git commit -m "feat: 实现用户登录功能"

# 5. 推送到远程仓库
git push origin feature/user-authentication

Commit Message 规范

遵循 Conventional Commits 规范：

<type>(<scope>): <subject>

<body>

<footer>

常用 type 类型：

Type	说明	示例
`feat`	新功能	`feat: 添加用户注册接口`
`fix`	Bug 修复	`fix: 修复登录验证失败的问题`
`docs`	文档更新	`docs: 更新 API 使用说明`
`style`	代码格式调整	`style: 统一代码缩进为 2 空格`
`refactor`	代码重构	`refactor: 优化数据库查询逻辑`
`test`	测试相关	`test: 添加用户模块单元测试`
`chore`	构建/工具变动	`chore: 升级依赖包版本`
`perf`	性能优化	`perf: 优化图片加载速度`

创建 Pull Request

1	# 推送分支后，在 GitHub/GitLab 上创建 PR

PR 标题规范：

feat: 新增用户认证功能

## 变更说明
- 实现了登录接口
- 添加了 JWT token 验证
- 增加了单元测试覆盖

## 测试
- [x] 单元测试通过
- [x] 集成测试通过
- [x] 手动测试通过

## 相关 Issue
Closes #123

合并策略

推荐使用 Squash Merge：

1 2	# 在 GitHub/GitLab 上选择 "Squash and merge" # 这样会将多个 commit 合并为一个，保持历史整洁

合并后清理：

# 1. 切换回 develop
git checkout develop

# 2. 拉取最新代码
git pull origin develop

# 3. 删除本地 feature 分支
git branch -d feature/user-authentication

# 4. 删除远程 feature 分支
git push origin --delete feature/user-authentication

2️⃣ 版本发布

创建 Release 分支

当 develop 分支积累了足够的功能，准备发布新版本时：

# 1. 确保 develop 是最新的
git checkout develop
git pull origin develop

# 2. 创建 release 分支（使用语义化版本号）
git checkout -b release/1.2.0

# 3. 推送到远程
git push origin release/1.2.0

语义化版本号（Semantic Versioning）

格式：MAJOR.MINOR.PATCH（主版本号.次版本号.修订号）

版本位	何时增加	示例
MAJOR	不兼容的 API 变更	`1.0.0` → `2.0.0`
MINOR	向后兼容的新功能	`1.1.0` → `1.2.0`
PATCH	向后兼容的问题修复	`1.1.1` → `1.1.2`

Release 分支上的工作

# 1. 更新版本号（根据项目类型）
# 对于 Node.js 项目
npm version 1.2.0

# 对于 Python 项目
# 修改 setup.py 或 pyproject.toml 中的版本号

# 2. 更新 CHANGELOG.md
# 记录本次发布的所有变更

# 3. 修复发现的小 bug
git add .
git commit -m "fix: 修复发布前发现的小问题"

# 4. 更新文档
git commit -m "docs: 更新版本发布说明"

完成发布

# 1. 合并到 main 分支
git checkout main
git pull origin main
git merge --no-ff release/1.2.0 -m "Release version 1.2.0"

# 2. 打标签
git tag -a v1.2.0 -m "Release version 1.2.0

新增功能：
- 用户认证系统
- 数据导出功能

Bug 修复：
- 修复内存泄漏问题
- 修复界面显示错误"

# 3. 推送 main 和 tag
git push origin main
git push origin v1.2.0

# 4. 合并回 develop（保持同步）
git checkout develop
git pull origin develop
git merge --no-ff release/1.2.0 -m "Merge release/1.2.0 back to develop"
git push origin develop

# 5. 删除 release 分支
git branch -d release/1.2.0
git push origin --delete release/1.2.0

自动化发布（GitHub Actions 示例）

# .github/workflows/release.yml
name: Release

on:
  push:
    tags:
      - 'v*'

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Build
        run: npm run build
      
      - name: Create Release
        uses: actions/create-release@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          tag_name: ${{ github.ref }}
          release_name: Release ${{ github.ref }}
          draft: false
          prerelease: false

3️⃣ 紧急修复（Hotfix）

什么时候需要 Hotfix？

当生产环境（main 分支）出现严重 bug，需要立即修复时使用 hotfix 分支。

典型场景：

🔥 安全漏洞
💥 系统崩溃
🐛 影响核心功能的严重 bug
📉 性能严重下降

创建 Hotfix 分支

# 1. 从 main 分支创建 hotfix 分支
git checkout main
git pull origin main
git checkout -b hotfix/1.2.1

# 2. 推送到远程（可选，如果需要协作）
git push origin hotfix/1.2.1

修复问题

# 1. 修复 bug
# ... 编写修复代码 ...

# 2. 提交修复
git add .
git commit -m "fix: 修复用户登录时的安全漏洞"

# 3. 测试验证
# 确保修复有效且没有引入新问题

完成 Hotfix

# 1. 合并到 main 分支
git checkout main
git merge --no-ff hotfix/1.2.1 -m "Hotfix 1.2.1: 修复安全漏洞"

# 2. 打标签（递增 PATCH 版本号）
git tag -a v1.2.1 -m "Hotfix 1.2.1

紧急修复：
- 修复用户登录时的安全漏洞
- 加强输入验证"

# 3. 推送到远程
git push origin main
git push origin v1.2.1

# 4. 合并到 develop（避免 develop 缺少修复）
git checkout develop
git pull origin develop
git merge --no-ff hotfix/1.2.1 -m "Merge hotfix/1.2.1 into develop"
git push origin develop

# 5. 如果存在 release 分支，也要合并
git checkout release/1.3.0  # 如果存在
git merge --no-ff hotfix/1.2.1
git push origin release/1.3.0

# 6. 删除 hotfix 分支
git branch -d hotfix/1.2.1
git push origin --delete hotfix/1.2.1

快速 Hotfix 命令脚本

创建一个脚本文件 hotfix.sh 来自动化流程：

#!/bin/bash
# hotfix.sh - Git Flow Hotfix 自动化脚本

set -e

# 读取参数
VERSION=$1
MESSAGE=$2

if [ -z "$VERSION" ] || [ -z "$MESSAGE" ]; then
    echo "用法: ./hotfix.sh <version> <message>"
    echo "示例: ./hotfix.sh 1.2.1 '修复安全漏洞'"
    exit 1
fi

BRANCH="hotfix/$VERSION"

echo "🚀 开始 Hotfix 流程: $VERSION"

# 1. 从 main 创建分支
echo "📝 创建 hotfix 分支..."
git checkout main
git pull origin main
git checkout -b $BRANCH

echo "⚠️  请在 $BRANCH 分支上修复问题，完成后按回车继续..."
read

# 2. 合并到 main
echo "🔀 合并到 main..."
git checkout main
git merge --no-ff $BRANCH -m "Hotfix $VERSION: $MESSAGE"
git tag -a "v$VERSION" -m "Hotfix $VERSION: $MESSAGE"
git push origin main
git push origin "v$VERSION"

# 3. 合并到 develop
echo "🔀 合并到 develop..."
git checkout develop
git pull origin develop
git merge --no-ff $BRANCH -m "Merge $BRANCH into develop"
git push origin develop

# 4. 清理
echo "🧹 清理分支..."
git branch -d $BRANCH
git push origin --delete $BRANCH

echo "✅ Hotfix $VERSION 完成！"

使用方法：

1 2	chmod +x hotfix.sh ./hotfix.sh 1.2.1 "修复用户登录安全漏洞"

✅ 配合工具

工具	用途	配置难度
git-flow	Git Flow 命令行工具	⭐ 简单
GitHub Actions / GitLab CI	自动化 CI/CD	⭐⭐ 中等
pre-commit hooks	提交前自动检查	⭐ 简单
Conventional Commits	规范提交信息	⭐ 简单
commitlint	验证提交信息格式	⭐⭐ 中等
husky	Git hooks 管理	⭐ 简单
Release Please	自动生成 CHANGELOG	⭐⭐⭐ 复杂
semantic-release	自动版本管理	⭐⭐⭐ 复杂

git-flow 工具使用

安装 git-flow：

# macOS
brew install git-flow

# Ubuntu/Debian
apt-get install git-flow

# Windows (Git Bash)
# 下载并安装 git-flow-windows

使用 git-flow 简化操作：

# 初始化 git-flow
git flow init

# 开始新功能
git flow feature start user-login

# 完成功能（自动合并到 develop）
git flow feature finish user-login

# 开始发布
git flow release start 1.2.0

# 完成发布（自动合并到 main 和 develop，并打 tag）
git flow release finish 1.2.0

# 开始热修复
git flow hotfix start 1.2.1

# 完成热修复
git flow hotfix finish 1.2.1

分支保护配置

在 GitHub/GitLab 上配置分支保护规则：

GitHub 配置

进入：Settings → Branches → Branch protection rules

保护 main 分支：

✅ Require pull request reviews before merging
✅ Require status checks to pass before merging
✅ Require branches to be up to date before merging
✅ Include administrators
✅ Restrict who can push to matching branches

保护 develop 分支：

✅ Require pull request reviews before merging
✅ Require status checks to pass before merging
✅ Require branches to be up to date before merging

GitLab 配置

进入：Settings → Repository → Protected branches

保护规则：

分支	允许合并	允许推送
`main`	Maintainers	No one
`develop`	Developers + Maintainers	Developers + Maintainers

CI/CD 配置示例

GitHub Actions 完整配置

# .github/workflows/ci.yml
name: CI

on:
  pull_request:
    branches: [develop, main]
  push:
    branches: [develop, main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'
          cache: 'npm'
      
      - name: Install dependencies
        run: npm ci
      
      - name: Run linter
        run: npm run lint
      
      - name: Run tests
        run: npm test
      
      - name: Build
        run: npm run build
      
      - name: Upload coverage
        uses: codecov/codecov-action@v3
        with:
          token: ${{ secrets.CODECOV_TOKEN }}

Husky + Commitlint 配置

安装依赖：

1	npm install --save-dev @commitlint/cli @commitlint/config-conventional husky

配置 commitlint.config.js：

module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    'type-enum': [
      2,
      'always',
      [
        'feat',     // 新功能
        'fix',      // Bug 修复
        'docs',     // 文档更新
        'style',    // 代码格式
        'refactor', // 重构
        'perf',     // 性能优化
        'test',     // 测试
        'chore',    // 构建/工具
        'revert',   // 回滚
        'build',    // 构建系统
        'ci'        // CI 配置
      ]
    ],
    'subject-case': [0] // 允许任意大小写
  }
};

初始化 husky：

# 初始化 husky
npx husky init

# 添加 commit-msg hook
echo "npx --no -- commitlint --edit \$1" > .husky/commit-msg

# 添加 pre-commit hook
echo "npm run lint && npm test" > .husky/pre-commit

💬 实战建议

📊 不同团队规模的策略

小型团队（1-3 人）

简化版 Git Flow：

只保留 main 分支
功能开发从 main 拉 feature/*
完成后直接合并回 main
紧急修复使用 hotfix/*

中型团队（4-10 人）

标准 Git Flow（推荐）：

完整的 main + develop + feature/* + release/* + hotfix/*
使用 PR/MR 进行代码审查
配置基本的 CI/CD
强制执行分支保护

大型团队（10+ 人）

增强版 Git Flow：

完整的 Git Flow
每个 feature 必须关联 Issue
强制代码审查（至少 2 人）
完整的 CI/CD 流程
自动化测试覆盖率要求（如 80%+）
自动化版本发布和 CHANGELOG 生成

⚠️ 常见陷阱与解决方案

问题	原因	解决方案
合并冲突频繁	feature 分支存活时间过长	① 保持 feature 分支小而专注 ② 定期从 develop rebase ③ 及时合并完成的功能
版本混乱	没有遵循语义化版本	① 使用 semantic-release 自动管理 ② 建立版本号规范文档
hotfix 忘记合并到 develop	流程不熟悉	① 使用自动化脚本 ② 在合并 checklist 中明确标注
main 分支被直接推送	没有配置分支保护	① 立即配置分支保护规则 ② 只允许通过 PR 合并
提交信息混乱	缺少规范	① 使用 commitlint 强制规范 ② 提供提交模板

✨ 最佳实践清单

✅ 分支命名规范：使用统一的前缀（feature/, hotfix/, release/）
✅ 提交信息规范：遵循 Conventional Commits
✅ 代码审查：所有合并都需要至少一人审查
✅ 自动化测试：PR 必须通过所有测试
✅ 分支保护：禁止直接推送到 main 和 develop
✅ 定期清理：删除已合并的 feature 分支
✅ 文档更新：功能变更同步更新文档
✅ 版本标签：每次发布都打带注释的 tag
✅ CHANGELOG：自动或手动维护变更日志
✅ 回滚计划：每次发布都要有回滚预案

🎯 实施路线图

第 1 周：基础设施

创建 develop 分支
配置分支保护规则
设置基本的 CI 流程
团队培训：Git Flow 基础

第 2-3 周：规范建立

引入 Conventional Commits
配置 commitlint + husky
编写团队规范文档
创建 PR/MR 模板

第 4 周：自动化

配置完整的 CI/CD
引入自动化测试
配置代码覆盖率报告
尝试自动化发布

第 5 周及以后：优化

收集团队反馈
优化流程痛点
引入更多自动化工具
持续改进

📚 延伸阅读

Git Flow 原始博文 - Vincent Driessen
GitHub Flow - GitHub 官方文档
GitLab Flow - GitLab 官方文档
Semantic Versioning - 语义化版本规范
Conventional Commits - 约定式提交规范
Trunk Based Development - 另一种分支策略

🎓 总结

Git Flow 是一套成熟、可靠的分支管理策略，特别适合：

✅ 有明确发布周期的项目
✅ 需要同时维护多个版本
✅ 团队规模较大（5人以上）
✅ 对稳定性要求高的生产环境

核心要点：

两个长期分支：main（生产）+ develop（开发）
三种临时分支：feature/*（功能）+ release/*（发布）+ hotfix/*（修复）
规范化流程：从创建分支到合并都有明确步骤
自动化优先：用工具减少人为错误
团队协作：通过 PR/MR 进行代码审查

记住：Git Flow 不是银弹，根据团队实际情况灵活调整才是王道！🎉

Git Flow 从入门到精通

https://blog.ailln.com/v2ai/2025/10/25/git/6-git-flow/

作者

Ailln

发布于

2025-10-25

更新于

2025-10-29

许可协议

#Git

Git Flow 从入门到精通

💡 一句话理解 Git Flow

🧭 Git Flow 核心分支模型

🔧 执行规范建议（开源项目可执行版）

1️⃣ 新功能开发

创建 Feature 分支

分支命名规范

开发与提交

Commit Message 规范

创建 Pull Request

合并策略

2️⃣ 版本发布

创建 Release 分支

语义化版本号（Semantic Versioning）

Release 分支上的工作

完成发布

自动化发布（GitHub Actions 示例）

3️⃣ 紧急修复（Hotfix）

什么时候需要 Hotfix？

创建 Hotfix 分支

修复问题

完成 Hotfix

快速 Hotfix 命令脚本

✅ 配合工具

推荐工具集

git-flow 工具使用

分支保护配置

GitHub 配置

GitLab 配置

CI/CD 配置示例

GitHub Actions 完整配置

Husky + Commitlint 配置

💬 实战建议

📊 不同团队规模的策略

小型团队（1-3 人）

中型团队（4-10 人）

大型团队（10+ 人）

⚠️ 常见陷阱与解决方案

✨ 最佳实践清单

🎯 实施路线图

第 1 周：基础设施

第 2-3 周：规范建立

第 4 周：自动化

第 5 周及以后：优化

📚 延伸阅读

🎓 总结

作者

发布于

更新于

许可协议

喜欢这篇文章？打赏一下作者吧

评论

分类

归档

最新文章

标签