1. Git分支策略设计1.1 主分支结构main (主分支)
├── develop (开发分支)
│ ├── feature/article-template (功能分支)
│ ├── feature/review-system (功能分支)
│ ├── feature/seo-optimization (功能分支)
│ └── feature/batch-tools (功能分支)
├── release/v1.0.0 (发布分支)
├── hotfix/critical-bug (热修复分支)
└── hotfix/security-patch (安全修复分支)
1.2 分支命名规范功能分支（Feature Branches）命名格式：feature/功能描述示例：feature/article-template、feature/review-system用途：开发新功能源分支：develop目标分支：develop发布分支（Release Branches）命名格式：release/版本号示例：release/v1.0.0、release/v1.1.0用途：准备发布新版本源分支：develop目标分支：main热修复分支（Hotfix Branches）命名格式：hotfix/修复描述示例：hotfix/critical-bug、hotfix/security-patch用途：修复生产环境的紧急问题源分支：main目标分支：main 和 develop支持分支（Support Branches）命名格式：support/支持描述示例：support/legacy-compatibility用途：为旧版本提供支持源分支：main1.3 分支权限管理主分支保护规则# .github/workflows/branch-protection.yml
name: Branch Protection Rules
on:
pull_request:
branches: [ main, develop ]
jobs:
protect-main-branch:
runs-on: ubuntu-latest
steps:
name: Check PR source branch
run: |
if [[ "${{ github.head_ref }}" != release/* ]] && [[ "${{ github.head_ref }}" != hotfix/* ]]; then
echo "❌ 只能从release或hotfix分支合并到main分支"
exit 1
fi
name: Require PR reviews
uses: hmarr/auto-approve-action@v2
with:
review-requirement: 2 # 需要2个review
name: Require status checks
uses: github/require-status-checks-action@v1
with:
required_status_checks: |
build
test
lint
security-scan
2. 工作流程规范2.1 功能开发流程# 1. 从develop分支创建功能分支
git checkout develop
git pull origin develop
git checkout -b feature/article-template
# 2. 开发完成后推送到远程
git add .
git commit -m "feat: 新增文章模板功能
添加多种文章模板
支持模板自定义
优化模板渲染性能
Closes #123"
git push origin feature/article-template
# 3. 创建Pull Request到develop分支
# 在GitHub上创建PR，填写模板信息
# 4. Code Review通过后合并
git checkout develop
git merge --no-ff feature/article-template
git push origin develop
# 5. 删除功能分支
git branch -d feature/article-template
git push origin --delete feature/article-template
2.2 发布流程# 1. 创建发布分支
git checkout develop
git pull origin develop
git checkout -b release/v1.0.0
# 2. 更新版本号和文档
# 修改 package.json, CHANGELOG.md等文件
# 3. 修复测试中发现的问题（不添加新功能）
# 提交修复 commit
git commit -m "fix: 修复发布前的已知问题"
# 4. 合并到main分支
git checkout main
git merge --no-ff release/v1.0.0
git tag -a v1.0.0 -m "Release version 1.0.0"
git push origin main --tags
# 5. 合并回develop分支
git checkout develop
git merge --no-ff release/v1.0.0
git push origin develop
# 6. 删除发布分支
git branch -d release/v1.0.0
git push origin --delete release/v1.0.0
2.3 热修复流程# 1. 创建热修复分支
git checkout main
git pull origin main
git checkout -b hotfix/critical-bug
# 2. 修复问题并提交
git commit -m "fix: 修复关键bug
修复文章发布失败问题
优化错误处理逻辑
Hotfix: #456"
# 3. 测试通过后合并到main
git checkout main
git merge --no-ff hotfix/critical-bug
git tag -a v1.0.1 -m "Hotfix version 1.0.1"
git push origin main --tags
# 4. 合并到develop分支
git checkout develop
git merge --no-ff hotfix/critical-bug
git push origin develop
# 5. 删除热修复分支
git branch -d hotfix/critical-bug
git push origin --delete hotfix/critical-bug
3. 回滚策略3.1 代码回滚策略场景一：回滚到上一个稳定版本# 查看提交历史
git log --oneline -10
# 方法1：使用git revert（推荐，不会丢失历史）
git revert HEAD~3..HEAD # 回滚最近3个commit
# 方法2：使用git reset（会丢失历史，谨慎使用）
git reset --hard HEAD~3 # 回退到前3个commit
git push origin main --force # 需要强制推送
# 方法3：回滚到指定的tag
git checkout v1.0.0
git checkout -b rollback-to-v1.0.0
git checkout main
git reset --hard rollback-to-v1.0.0
git push origin main --force
场景二：回滚单个有问题的commit# 找到有问题的commit ID
git log --oneline
# 使用git revert回滚指定的commit
git revert <commit-id>
# 如果有冲突，解决冲突后
git add .
git commit -m "Revert \"有问题的commit消息\""
git push origin main
场景三：回滚已经合并的PR# 找到合并PR时产生的merge commit
git log --oneline --grep="Merge pull request"
# 回滚merge commit
git revert -m 1 <merge-commit-id>
# 解释：-m 1 表示保留main分支的更改，回滚被合并的分支
3.2 数据库回滚策略数据库迁移回滚// 在迁移文件中添加回滚逻辑
exports.up = function(knex) {
return knex.schema.createTable('articles', function(table) {
table.increments('id');
table.string('title');
table.text('content');
table.timestamps();
});
};
exports.down = function(knex) {
return knex.schema.dropTable('articles');
};
// 回滚命令
// knex migrate:rollback
// knex migrate:rollback --all // 回滚所有迁移
数据备份回滚#!/bin/bash
# 数据库备份和回滚脚本
# 备份数据库
backup_database() {
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="backup_${DATE}.sql"
pg_dump -h localhost -U postgres article_system > "${BACKUP_FILE}"
echo "数据库备份完成: ${BACKUP_FILE}"
}
# 回滚数据库
rollback_database() {
BACKUP_FILE=$1
if [ -f "${BACKUP_FILE}" ]; then
psql -h localhost -U postgres -d article_system < "${BACKUP_FILE}"
echo "数据库回滚完成: ${BACKUP_FILE}"
else
echo "备份文件不存在: ${BACKUP_FILE}"
exit 1
fi
}
# 使用示例
backup_database
# rollback_database "backup_20241201_120000.sql"
3.3 文件系统回滚策略使用Git LFS管理大文件# 安装Git LFS
git lfs install
# 跟踪大文件类型
git lfs track "*.pdf"
git lfs track "*.zip"
git lfs track "images/*.png"
# 提交后，大文件会被存储在LFS中
git add .gitattributes
git add images/large-file.png
git commit -m "Add large image file"
# 回滚大文件版本
git log --follow -- images/large-file.png
git checkout <commit-id> -- images/large-file.png
使用版本控制系统管理配置文件# docker-compose.yml 版本管理
version: '3.8'
services:
app:
image: article-system:${VERSION:-latest}
volumes:
./config:/app/config
./uploads:/app/uploads
./backups:/app/backups
environment:
NODE_ENV=production
VERSION=${VERSION}
4. 自动化回滚机制4.1 CI/CD流水线回滚# .github/workflows/rollback.yml
name: Automated Rollback
on:
workflow_dispatch:
inputs:
version:
description: 'Version to rollback to'
required: true
type: string
environment:
description: 'Environment'
required: true
type: choice
options:
staging
production
jobs:
rollback:
runs-on: ubuntu-latest
steps:
name: Checkout code
uses: actions/checkout@v3
with:
fetch-depth: 0
name: Rollback application
run: |
# 回滚代码到指定版本
git checkout ${{ github.event.inputs.version }}
# 构建回滚版本
npm ci
npm run build
# 部署回滚版本
npm run deploy:${{ github.event.inputs.environment }}
name: Rollback database
if: ${{ github.event.inputs.environment == 'production' }}
run: |
# 数据库回滚
npm run db:rollback:to ${{ github.event.inputs.version }}
name: Verify rollback
run: |
# 健康检查
npm run health:check
# 如果健康检查失败，发送警报
if [ $? -ne 0 ]; then
npm run alert:rollback:failed
exit 1
fi
name: Notify rollback result
run: |
# 发送回滚结果通知
npm run notify:rollback:success
4.2 监控告警触发回滚// 监控告警配置
const rollbackConfig = {
triggers: {
errorRate: {
threshold: 0.05, // 错误率超过5%
duration: 300, // 持续5分钟
action: 'rollback'
},
responseTime: {
threshold: 5000, // 响应时间超过5秒
duration: 600, // 持续10分钟
action: 'rollback'
},
availability: {
threshold: 0.95, // 可用性低于95%
duration: 180, // 持续3分钟
action: 'rollback'
}
},
rollbackStrategy: {
automatic: true,
maxRollbackTime: 3600, // 最大回滚时间1小时
notifyChannels: ['email', 'slack', 'sms'],
approvalRequired: false // 紧急情况下自动回滚
}
};
// 自动回滚逻辑
async function autoRollback(metric, threshold) {
const deployments = await getRecentDeployments(5);
const previousStableVersion = deployments[1]; // 上一个稳定版本
console.log(触发自动回滚: ${metric}超过阈值${threshold});
console.log(回滚到版本: ${previousStableVersion});
try {
await triggerRollback(previousStableVersion);
await notifyRollbackSuccess(previousStableVersion);
} catch (error) {
console.error('自动回滚失败:', error);
await notifyRollbackFailure(error);
}
}
5. 回滚最佳实践5.1 回滚前检查清单## 回滚前检查清单
技术检查
[ ] 确认回滚目标版本
[ ] 检查回滚版本的功能完整性
[ ] 验证数据库兼容性
[ ] 确认配置文件兼容性
[ ] 检查依赖项版本
业务检查
[ ] 评估回滚影响范围
[ ] 通知相关业务方
[ ] 准备回滚后验证方案
[ ] 制定紧急恢复计划
[ ] 确认维护时间窗口
数据检查
[ ] 备份当前数据
[ ] 确认数据迁移脚本
[ ] 检查数据一致性
[ ] 验证回滚后数据完整性
5.2 回滚后验证#!/bin/bash
# 回滚后验证脚本
echo "开始回滚后验证..."
# 1. 服务健康检查
echo "1. 检查服务健康状态..."
curl -f http://localhost:3000/health || exit 1
# 2. 数据库连接检查
echo "2. 检查数据库连接..."
node -e "
const { Pool } = require('pg');
const pool = new Pool({
connectionString: process.env.DATABASE_URL
});
pool.query('SELECT 1', (err, res) => {
if (err) {
console.error('数据库连接失败:', err);
process.exit(1);
}
console.log('数据库连接正常');
pool.end();
});
"
# 3. 核心功能测试
echo "3. 测试核心功能..."
npm run test:core
# 4. 性能基准测试
echo "4. 性能基准测试..."
npm run test:performance
# 5. 生成验证报告
echo "5. 生成验证报告..."
npm run generate:rollback:report
echo "回滚验证完成！"
5.3 回滚记录和复盘# 回滚记录模板
回滚基本信息
回滚时间：2024-12-01 15:30:00
回滚原因：新版本导致文章发布功能异常
回滚版本：从v1.2.0回滚到v1.1.5
执行人：张三
回滚耗时：15分钟
影响范围
受影响功能：文章发布、编辑、审核
受影响用户：所有内容创作者
业务影响：无法发布新文章，编辑功能异常
数据影响：无数据丢失
回滚过程
1. 15:25 - 发现问题，评估需要回滚
2. 15:27 - 备份当前数据和配置
3. 15:30 - 开始执行回滚
4. 15:35 - 代码回滚完成
5. 15:40 - 数据库回滚完成
6. 15:42 - 服务重启，验证功能
7. 15:45 - 回滚完成，功能恢复
经验教训
做得好的地方
监控系统及时发现问题
回滚流程执行顺利
数据备份完整
需要改进的地方
新版本测试不充分
灰度发布范围太小
回滚自动化程度不够
后续行动计划
发表评论 取消回复