沃以的小站

Appearance

Git 分支策略 ​

分支模型 ​

我采用了基于 Git Flow 的简化分支策略，适合个人博客项目的开发和维护。

主要分支 ​

1. master 分支 ​

  • 用途: 生产环境分支，始终保持稳定可发布状态
  • 保护级别: 高度保护，只允许通过 PR 合并
  • 部署: 自动部署到 GitHub Pages 生产环境
  • 命名规范: master

2. develop 分支 ​

  • 用途: 开发主分支，集成所有功能开发
  • 保护级别: 中等保护，允许直接推送但建议通过 PR
  • 部署: 自动部署到预览环境（如果配置）
  • 命名规范: develop

3. doc 分支 ​

  • 用途: 文档专用分支，用于文档编写和维护
  • 保护级别: 低保护，允许直接推送
  • 部署: 可选择性部署到文档预览环境
  • 命名规范: doc

辅助分支 ​

Feature 分支 ​

  • 用途: 新功能开发
  • 来源: 从 develop 分支创建
  • 合并目标: 合并回 develop 分支
  • 命名规范: feature/功能名称 或 feature/issue-编号
  • 生命周期: 功能完成后删除

Hotfix 分支 ​

  • 用途: 紧急修复生产环境问题
  • 来源: 从 master 分支创建
  • 合并目标: 同时合并到 master 和 develop 分支
  • 命名规范: hotfix/问题描述 或 hotfix/版本号
  • 生命周期: 修复完成后删除

Release 分支 ​

  • 用途: 发布准备，版本测试和修复
  • 来源: 从 develop 分支创建
  • 合并目标: 合并到 master 和 develop 分支
  • 命名规范: release/版本号
  • 生命周期: 发布完成后删除

工作流程 ​

日常开发流程 ​

  1. 新功能开发

    bash
    # 从 develop 创建 feature 分支
git checkout develop
git pull origin develop
git checkout -b feature/new-post-template

# 开发完成后提交
git add .
git commit -m "feat: 添加新的文章模板"
git push origin feature/new-post-template

# 创建 PR 合并到 develop

  2. 文档编写流程

    bash
    # 在 doc 分支上直接工作
git checkout doc
git pull origin doc

# 编写文档
git add .
git commit -m "docs: 更新分支策略文档"
git push origin doc

  3. 发布流程

    bash
    # 创建 release 分支
git checkout develop
git pull origin develop
git checkout -b release/v1.1.0

# 进行发布前的最后测试和修复
git add .
git commit -m "chore: 准备 v1.1.0 发布"

# 合并到 master
git checkout master
git pull origin master
git merge --no-ff release/v1.1.0
git tag -a v1.1.0 -m "Release version 1.1.0"
git push origin master --tags

# 合并回 develop
git checkout develop
git merge --no-ff release/v1.1.0
git push origin develop

# 删除 release 分支
git branch -d release/v1.1.0
git push origin --delete release/v1.1.0

紧急修复流程 ​

bash
# 从 master 创建 hotfix 分支
git checkout master
git pull origin master
git checkout -b hotfix/fix-broken-link

# 修复问题
git add .
git commit -m "fix: 修复文章中的错误链接"

# 合并到 master
git checkout master
git merge --no-ff hotfix/fix-broken-link
git tag -a v1.0.1 -m "Hotfix version 1.0.1"
git push origin master --tags

# 合并到 develop
git checkout develop
git merge --no-ff hotfix/fix-broken-link
git push origin develop

# 删除 hotfix 分支
git branch -d hotfix/fix-broken-link
git push origin --delete hotfix/fix-broken-link

提交规范 ​

我们采用 Conventional Commits 规范：

提交格式 ​

text
<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

常用类型 ​

  • feat: 新功能
  • fix: 修复问题
  • docs: 文档变更
  • style: 代码样式变更（不影响功能）
  • refactor: 重构代码
  • perf: 性能优化
  • test: 添加或修改测试
  • chore: 构建过程或辅助工具的变动
  • ci: CI/CD 相关变更

示例 ​

bash
feat(blog): 添加新的文章分类功能
fix(style): 修复移动端导航栏显示问题
docs(readme): 更新安装说明
chore(deps): 升级 VitePress 到最新版本

分支保护规则 ​

Master 分支保护 ​

  • 禁止直接推送
  • 需要 Pull Request 审核
  • 需要状态检查通过
  • 需要分支是最新的

Develop 分支保护 ​

  • 允许直接推送（建议通过 PR）
  • 建议代码审核
  • 需要基本的CI检查通过

版本管理 ​

语义化版本控制 ​

采用 Semantic Versioning 规范：

  • 主版本号(MAJOR): 不兼容的重大变更
  • 次版本号(MINOR): 向后兼容的功能性新增
  • 修订号(PATCH): 向后兼容的问题修正

标签规范 ​

  • 格式：vX.Y.Z
  • 示例：v1.0.0, v1.2.3, v2.0.0-beta.1

最佳实践 ​

  1. 保持分支同步: 定期将 develop 的更新合并到 feature 分支
  2. 小而频繁的提交: 避免大型提交，便于代码审核和问题定位
  3. 有意义的提交信息: 清晰描述变更内容和原因
  4. 删除已合并的分支: 保持分支列表整洁
  5. 使用 Pull Request: 即使是个人项目，也建议通过 PR 进行代码审核
  6. 定期清理: 定期删除过期的本地和远程分支

自动化工具 ​

配合 GitHub Actions 实现自动化：

  • 自动构建和测试
  • 自动部署到不同环境
  • 自动检查提交规范
  • 自动生成变更日志

上次更新于: