【游戏项目】大型项目Git分支策略与开发流程设计构想

一、分支模型设计

对于游戏项目开发，我推荐采用改进的Git Flow模型，根据游戏开发特点进行调整：

Git Flow是由Vincent Driessen提出的分支模型，它定义了不同的分支类型，比如主分支、开发分支、功能分支、发布分支和热修复分支。

主要分支

1. main/master分支

   • 生产环境代码，对应已发布的版本
   • 只允许通过发布分支合并
   • 每个提交都应打上版本标签(v1.0.0)

2. develop分支

   • 集成分支，包含最新的开发成果
   • 所有功能分支最终合并到这里
   • 用于日常构建和测试

辅助分支

3. feature/功能分支

   • 从develop分支创建
   • 命名规范：feature/[功能名]-[JIRA编号](如feature/combat-system-PROJ-123)
   • 开发完成后合并回develop分支
   • 不保留长期存在的功能分支

4. release/发布分支

   • 从develop分支创建(当功能集足够发布新版本时)
   • 命名规范：release/[版本号](如release/1.2.0)
   • 用于版本测试、bug修复和最终发布准备
   • 发布后合并到main和develop分支

5. hotfix/热修复分支

   • 从main分支创建(针对线上紧急问题)
   • 命名规范：hotfix/[简短描述]-[版本号](如hotfix/crash-fix-1.2.1)
   • 修复后合并回main和develop分支

二、开发流程

2.1 日常开发流程

1. 从develop分支创建功能分支

   git checkout develop
   git pull origin develop
   git checkout -b feature/new-feature-PROJ-456
   

2. 在功能分支上进行开发，定期提交

   git add .
   git commit -m "PROJ-456: 实现基础战斗系统"
   

3. 开发完成后，推送到远程仓库并创建Pull Request

   git push origin feature/new-feature-PROJ-456
   

4. 代码审查通过后，合并到develop分支

2.2 版本发布流程

1. 当develop分支功能足够发布时，创建release分支

   git checkout develop
   git pull origin develop
   git checkout -b release/1.3.0
   

2. 在release分支上进行最终测试和bug修复

3. 准备发布：

   • 更新版本号
   • 更新CHANGELOG.md
   • 进行最终构建验证

4. 发布完成：

   git checkout main
   git merge --no-ff release/1.3.0
   git tag -a v1.3.0 -m "版本1.3.0发布"
   git push origin main --tagsgit checkout develop
   git merge --no-ff release/1.3.0
   git push origin develop
   

5. 删除release分支

   git branch -d release/1.3.0
   

3. 热修复流程

1. 从main分支创建hotfix分支

   git checkout main
   git pull origin main
   git checkout -b hotfix/crash-fix-1.3.1
   

2. 进行紧急修复并测试

3. 完成修复：

   git checkout main
   git merge --no-ff hotfix/crash-fix-1.3.1
   git tag -a v1.3.1 -m "热修复版本1.3.1"
   git push origin main --tagsgit checkout develop
   git merge --no-ff hotfix/crash-fix-1.3.1
   git push origin develop
   

4. 删除hotfix分支

   git branch -d hotfix/crash-fix-1.3.1
   

三、版本管理策略

3.1 版本号规范

采用语义化版本控制(SemVer)：MAJOR.MINOR.PATCH

• MAJOR: 重大架构变更或不兼容的API修改
• MINOR: 向下兼容的功能新增
• PATCH: 向下兼容的问题修正

3.2 版本控制实践

1. 预发布版本：在正式版本前可以发布alpha/beta版本

   • 1.2.0-alpha.1
   • 1.2.0-beta.2

2. 版本标签：每个正式发布都应打上标签

   git tag -a v1.2.0 -m "版本1.2.0发布"
   git push origin --tags
   

3. 版本回滚：如果发布后发现问题

   git checkout v1.1.0  # 回退到上一个稳定版本
   git checkout -b release/1.1.1
   # 进行修复并发布1.1.1版本
   

游戏项目特殊考虑

1. 资源文件管理：

   • 大文件使用Git LFS管理
   • 二进制资源文件避免频繁合并

2. 多平台支持：

   • 可以为不同平台创建特性分支
   • 使用构建配置管理平台差异

3. 长期功能分支：

   • 对于需要长时间开发的大型系统(如新战斗系统)
   • 定期从develop分支合并更新，避免后期合并冲突

4. 自动化集成：

   • 设置CI/CD流水线，自动构建和测试develop分支
   • 每次合并到develop都应触发构建验证

这种分支策略和开发流程提供了结构化的方法来管理游戏开发中的复杂性，同时保持了足够的灵活性来应对游戏开发中常见的变化和迭代需求。

---

四、实战

4.1 开发者开发A功能的详细操作流程

当开发者需要开发一个新功能（假设为"A功能"）时，应该按照以下步骤操作：

1. 准备阶段

1.1 确保本地develop分支是最新的

git checkout develop
git pull origin develop

1.2 创建功能分支

git checkout -b feature/A-feature-PROJ-123
# 分支命名规范：feature/[功能名]-[JIRA编号]
# 例如：feature/A-feature-PROJ-123

2. 开发阶段

2.1 在功能分支上进行开发

• 进行小步提交，每个提交应有明确的描述

git add .
git commit -m "PROJ-123: 实现A功能的基础框架"

2.2 定期同步develop分支的更新

git fetch origin
git merge origin/develop
# 或者使用rebase（如果更熟悉）
# git rebase develop

2.3 解决可能的合并冲突

• 如果合并或rebase过程中出现冲突，解决后继续

3. 阶段性推送

3.1 将本地分支推送到远程仓库

git push -u origin feature/A-feature-PROJ-123
# -u参数设置上游分支，之后可以简写git push

4. 完成开发准备合并

4.1 确保代码质量

• 通过所有单元测试
• 符合代码规范
• 更新相关文档

4.2 最后一次同步develop分支

git fetch origin
git merge origin/develop

4.3 推送最终代码

git push origin feature/A-feature-PROJ-123

5. 创建合并请求(Pull Request/Merge Request)

5.1 在Git平台(GitHub/GitLab等)上：

1. 导航到仓库页面
2. 点击"New Pull Request"或"Create Merge Request"
3. 选择:
   • base分支: develop
   • compare分支: feature/A-feature-PROJ-123
4. 填写PR/MR信息:
   • 标题: [PROJ-123] 实现A功能
   • 描述: 详细说明变更内容、测试方法等
   • 关联JIRA任务(如果有)
5. 指定审查者

6. 代码审查阶段

6.1 根据审查意见进行修改

# 在本地功能分支上修改
git add .
git commit -m "PROJ-123: 根据审查意见修复XX问题"
git push origin feature/A-feature-PROJ-123

6.2 审查通过后合并

• 通常由项目维护者执行合并
• 使用"Create a merge commit"选项(非fast-forward)
• 删除远程功能分支(可选)

7. 后续操作

7.1 更新本地仓库

git checkout develop
git pull origin develop

7.2 删除本地功能分支(可选)

git branch -d feature/A-feature-PROJ-123

最佳实践提示

1. 提交粒度：保持小颗粒度提交，每个提交只做一件事
2. 提交信息：遵循"类型(范围): 描述"格式，如：

  feat(A系统): 添加技能冷却功能fix(战斗): 修复伤害计算错误

3. 频繁同步：每天至少同步一次develop分支
4. 分支寿命：功能分支生命周期建议不超过2周
5. 代码审查：确保所有代码都经过审查才能合并

通过这种规范化的流程，可以确保功能开发有序进行，减少合并冲突，方便团队协作和代码追溯。

---

4.2 处理不需要立即发布的功能的开发流程

当develop分支包含一些不准备在当前版本发布的功能时，可以采用以下策略：

方案一：使用特性开关（Feature Flags）

1. 实现方式：

// 在代码中使用条件判断
if (FeatureFlags.IsEnabled("NEW_COMBAT_SYSTEM"))
{// 新战斗系统代码
}
else
{// 旧系统代码
}

2. 操作流程：

• 在配置系统中维护当前版本启用的功能列表
• 发布时关闭不需要的功能开关
• 下个版本再开启这些功能

优点：

• 不需要分支操作
• 可以动态控制功能
• 方便A/B测试

缺点：

• 代码中会存在未使用的代码路径
• 需要良好的开关管理机制

方案二：分支重构法

1. 操作步骤：

# 1. 从当前develop创建临时分支
git checkout -b temp/for_release_1.3 develop# 2. 回退不需要的功能提交
git revert commit_hash1 commit_hash2...  # 或使用交互式rebase# 3. 创建release分支
git checkout -b release/1.3 temp/for_release_1.3# 4. 发布后，将release分支合并回main
git checkout main
git merge --no-ff release/1.3# 5. 将原始develop分支重命名为next-release（可选）
git branch -m develop next-release# 6. 从main创建新的develop分支
git checkout main
git checkout -b develop# 7. 合并next-release中需要保留的功能
git merge feature/needed-feature

优点：

• 完全隔离不需要的功能
• 生产代码干净

缺点：

• 操作复杂
• 需要团队协调

方案三：选择性发布分支

1. 操作流程：

# 1. 从develop创建release分支
git checkout -b release/1.3 develop# 2. 在release分支上移除不需要的功能
# 使用git revert或手动删除# 3. 发布后
git checkout main
git merge --no-ff release/1.3
git tag v1.3.0# 4. 将release分支的修改合并回develop
git checkout develop
git merge --no-ff release/1.3# 5. 恢复被移除的功能（如有冲突需要解决）
git cherry-pick feature/A_commit1 feature/A_commit2...

方案四：功能分支隔离法（推荐）

1. 前期准备：

• 将长期功能放在独立命名空间的分支

  git checkout -b feature/A-next-version develop
  

2. 发布时操作：

# 1. 创建不包含长期功能分支的release分支
git checkout develop
git checkout -b release/1.3# 2. 如果有已合并但不需发布的功能，使用revert
git revert merge_commit_sha --no-commit
git commit -m "Revert feature/A for release 1.3"# 3. 发布后
git checkout main
git merge --no-ff release/1.3# 4. 在下个版本重新应用这些功能
git checkout develop
git cherry-pick feature/A-commit1 feature/A-commit2...

最佳实践建议

1. 规划阶段：

   • 使用里程碑(Milestone)明确功能归属版本
   • 在项目管理工具(Jira等)中标记功能的目标版本

2. 代码组织：

   • 将不同版本的功能放在不同模块/命名空间
   • 使用接口抽象可能变化的系统

3. 版本控制：

   # 查看哪些功能将被包含/排除
   git log develop ^main --oneline --no-merges
   

4. 文档记录：

   • 在CHANGELOG.md中明确标注"延后发布"的功能
   • 使用代码注释标记版本计划

   // [Planned for v1.4] 新存档系统
   

自动化工具辅助

1. 使用GitHub/GitLab的CODEOWNERS文件指定功能负责人

2. 配置CI流水线检查功能开关状态

   # .gitlab-ci.yml示例
   check_feature_flags:script:- ./scripts/verify_flags_for_release.sh
   

3. 使用分支保护规则限制直接向develop合并

选择哪种方案取决于：

• 团队规模
• 功能复杂度
• 发布频率
• 现有基础设施

对于大多数游戏项目，**方案一（特性开关）+ 方案四（功能分支隔离）**的组合通常是最佳选择，既能保持开发流程的流畅性，又能灵活控制功能发布。