docs/Git工作流规范.md
建立清晰、统一的 Git 工作流规范，解决团队协作中的冲突和代码丢失问题，同时有效管理开源和闭源两个版本的代码。
目前高频更新时期，针对开源版本的 GitHub Flow 工作流：
dev 分支
↓ Developer 新建功能分支
feat/hotfix 分支
↓ 开发、测试
↓ Pull Request
↓ Review
dev (合并回dev分支)
↓ 不定期完整测试
main (合并回main分支)
↓ 自动发布
Release Tag
分支规范：
main：唯一稳定分支dev：高频更新分支feat/功能描述 格式（从 dev 检出）hotfix/问题描述 格式（从 dev 检出）操作流程：
dev 分支创建功能/修复分支devdev稳定后main，自动触发 CI/CD 流程，发布 Release 并打 Tag完整测试频率建议：
针对闭源版本的 Git Flow 工作流：
test 分支(测试环境)
↓ Developer 新建功能分支
feat/hotfix 分支
↓ 开发、测试
↓ Pull Request
↓ Review
↓ 测试：测试人员拉取当前开发者的feature/hotfix分支，对feature/hotfix进行测试
test-cp (合并进test-cp分支测试)
↓ 完整测试 --> 失败回滚
test (合并进test分支)
↓ 合并test分支
↓ 更新test环境
main (合并回main分支)
↓ 自动发布
Release Tag
分支规范：
main：生产环境稳定分支test：测试环境分支（从 main 检出）-test-cp：测试者的临时测试环境分支（从 test 检出）feat/功能描述 格式（从 test 检出）hotfix/问题描述 格式（从 test 检出）操作流程：
开发场景：
1. test → 创建 feat/f-support-sql-driver
2. feat/f-support-sql-driver → 开发完成后PR
3. 测试人员拉取当前开发者的feature/hotfix分支合并到 test-cp，对test-cp进行测试
4. PR合并到 test
5. test测试验证通过 → 提交 PR 合并到 main
6. main → 完成自动触发 release 打 tag
上游 (开源版本) 下游 (闭源版本)
[公有仓库] [私有仓库]
| |
| |
开源核心代码 ←←←←←←←←←←← 商业版本完整代码
| |
| |
社区贡献 闭源功能
仓库结构：
单向流动原则：
开源main分支发布后， 团队讨论后决定是否合并到闭源
新建功能开发：
# 1. 切换到 dev 分支并更新
git checkout dev
git pull origin dev
# 2. 创建功能分支
git checkout -b feat/功能描述
# 3. 开发并提交代码
git add .
git commit -m "功能描述"
# 4. 推送分支到远程仓库
git push origin feat/功能描述
# 5. 在 GitHub 上创建 Pull Request
# 6. 代码审查通过后合并到dev
# 7. dev不定期完整测试后，并到main
新建功能开发：
# 1. 切换到 test 分支并更新
git checkout test
git pull origin test
# 2. 创建功能分支
git checkout -b feat/功能描述
# 3. 开发并提交代码
git add .
git commit -m "功能描述"
# 4. 推送分支到远程仓库
git push origin feat/功能描述
# 5. 在 GitHub 上创建 Pull Request
# 6. 测试人员拉取当前开发者的feature/hotfix分支并到 test-cp，对test-cp进行测试
# 7. 测试人员test-cp分支完整测试验证通过
# 8. 测试通过后PR合并到 test分支，更新测试环境
# 9. 提交 PR 合并到 main
# 10. main → 完成自动触发 release 打 tag
为了确保闭源版本能够及时获得开源版本的改进，团队需要定期讨论是否将公有仓库的更新同步到私有仓库
同步频率建议：
可以使用 GitHub Actions 来实现基于里程碑的自动发布，创建 .github/workflows/auto-release.yml 文件：
name: Auto Release on Milestone Completion
on:
milestone:
types: [closed]
workflow_dispatch:
inputs:
milestone_title:
description: 'Milestone title to release'
required: true
jobs:
release:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Get milestone info
id: milestone
run: |
if [ "${{ github.event_name }}" = "milestone" ]; then
MILESTONE_TITLE="${{ github.event.milestone.title }}"
MILESTONE_DESC="${{ github.event.milestone.description }}"
else
MILESTONE_TITLE="${{ github.event.inputs.milestone_title }}"
MILESTONE_DESC=""
fi
echo "milestone_title=$MILESTONE_TITLE" >> $GITHUB_OUTPUT
echo "milestone_description=$MILESTONE_DESC" >> $GITHUB_OUTPUT
- name: Create release tag
run: |
git config --global user.name 'github-actions[bot]'
git config --global user.email 'github-actions[bot]@users.noreply.github.com'
git tag -a "v${{ steps.milestone.outputs.milestone_title }}" -m "${{ steps.milestone.outputs.milestone_description }}"
git push origin "v${{ steps.milestone.outputs.milestone_title }}"
- name: Create GitHub Release
uses: actions/create-release@v1
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
tag_name: "v${{ steps.milestone.outputs.milestone_title }}"
release_name: "Release ${{ steps.milestone.outputs.milestone_title }}"
body: |
## Release Notes
${{ steps.milestone.outputs.milestone_description }}
### Features
- Feature 1
- Feature 2
### Bug Fixes
- Bug fix 1
- Bug fix 2
draft: false
prerelease: false
使用说明：
在将功能分支合并到 「test」/ 「dev」 分支时，可能会遇到代码冲突。为了解决这个问题并保持功能分支的独立性，推荐使用临时分支处理方式：
# 1. 创建临时分支用于解决冲突
git checkout -b test-tmp origin/test
# 2. 将功能分支合并到临时分支
git merge feat/功能分支名称
# 3. 解决冲突并提交
# 在编辑器中解决冲突文件
git add .
git commit -m "解决合并冲突"
# 4. 推送临时分支到远程仓库
git push origin test-tmp
# 5. 创建从 test-tmp 到 test 的 Pull Request
# 6. 代码审查通过后合并到 test 分支
# 7. 清理临时分支
git checkout test
git pull origin test
git branch -d test-tmp
git push origin --delete test-tmp
这种方式的优点：
角色说明
Feature/Hotfix 分支 ───● 从Dev检出创建分支[开]──────────● 开发&自测[开]──────────● 提交PR→dev[开]
Dev 分支 ● 接收PR/Review[评]───● 合并到 dev[评]───● dev 不定期完整测试[测/CI][通过?]───● 发起 PR：dev→main[维]
Main 分支 ───● Review[评]───────────● 合并到 main[维]───────────● Release + Tag[CI]────────▶
Feature/Hotfix 分支 ───● 从Test检出创建分支[开]───────────● 开发&自测[开]──────────● 提交PR→test[开] ● 修复并更新PR[开]────▶
╱
╱ 测试失败回路：test 未通过 → 返回修复并更新 PR）
Test 分支 ● 接收PR/Review[评]───● 合并到test-cp[维]───● 构建环境[CI]───● 回归测试[测][通过?]───● 合并进test，发起PR：test→main[维]
Main 分支 ● Review[评]──────────● 合并到 main[维]──────────● Release + Tag[CI]────────▶
说明
┌─────────────────────────────────────────────────────────────┐
│ 跨仓库代码流转模型 │
└─────────────────────────────────────────────────────────────┘
[公有仓库 - 开源版本] [私有仓库 - 闭源版本]
│ │
▼ ▼
新功能开发 商业功能开发
│ │
▼ ▼
代码审查 闭源功能集成
│ │
▼ │
合并到main │
│ │
▼ ▼
发布Release 定期同步开源更新
│ │
└─────────────────────────────────┘
│
▼
版本兼容性测试
提交信息规范：
<type>(<scope>): <subject>分支命名规范：
feat/功能简述hotfix/问题简述代码审查：
定期同步：