Главная Обзор Помощь
Регистрация Вход
torren
/
s_cherry_e
1
0
Ответвить 0
Файлы Задачи 0 Запросы на слияние 0 Вики
Дерево: 1347d08eb4
Ветки Метки
s_cherry_e
/
sr
/
docs
/
git-flow
/
版本流程.md

版本流程.md 16 KB
История Исходник

版本控制

在游戏中，版本控制将按照以下规则进行格式化：

命名规则

UAT

对游戏影响较大的主要版本发布。示例如下：

Client

更新无法通过热修复完成，必须经过 Google Play Store / App Store 审核流程 的内容。

Server

更新涉及不兼容的改动，需要进行补丁或数据迁移。

其他

  • 大型新功能变更
  • 现有功能的完全重构
  • 架构级变更

Hotfix

标准的小版本更新，仅包含较小的改动，例如：

  • 新的小功能
  • 对现有功能的修改
  • Bug 修复
  • 每周维护更新

Urgent

需要尽快发布的紧急更新，例如：

  • 修复游戏崩溃问题
  • 修复损坏的功能
  • 修复严重 Bug
  • 修复破坏游戏平衡的漏洞

版本号格式

游戏版本号将根据游戏中的改动进行更新。 版本号格式如下：

xx.yy.zz

不同类型更新对版本号的影响如下：

UAT

  • xx +1
  • yy 和 zz 重置为 0

示例：

2.5.2 → 3.0.0

Hotfix

  • xx 不变
  • yy +1
  • zz 重置为 0

示例：

2.5.2 → 2.6.0

Urgent

  • xx 和 yy 不变
  • zz +1

示例：

2.5.2 → 2.5.3

图示

版本号升级规则:

flowchart LR
  A["当前版本 xx.yy.zz"]

  A -->|"UAT：xx + 1
yy=0, zz=0"| B["新版本 (xx+1).0.0"]
  A -->|"Hotfix：yy + 1
zz=0"| C["新版本 xx.(yy+1).0"]
  A -->|"Urgent：zz + 1"| D["新版本 xx.yy.(zz+1)"]

Git 控制

Git 访问需要严格规则，以确保项目稳定性。

分支创建与规则

在版本规划确认后，由负责人（Project Manager）创建一些标准分支。

Main / Master

仓库中最重要的分支。

该分支必须完全对应当前对外发布的版本。

规则：

  • 只有负责人可以合并到该分支
  • 每个版本发布后进行合并
  • 不允许直接提交 commit
  • 只允许从以下分支合并：
    • Review
    • UAT
    • Hotfix
    • Urgent

Review

用于存储等待审核的最新主要版本。

目的：

防止在应用仍处于审核状态时出现紧急问题。 （如果审核期间合并到 master，将无法获取干净的公开版本）

规则：

  • 只有负责人可以合并到此分支
  • 发布到 Play Store 和 App Store 后立即合并到 Master
  • 不允许直接 commit
  • 只允许从 UAT 分支合并

如果审核失败：

  • 修改需要在对应的 UAT 分支完成
  • 再重新合并到 Review

UAT

用于存储即将发布的主要版本。

命名格式：

UAT/版本号
例如：UAT/2.0.0

规则：

  • 不允许直接 commit
  • 所有修改必须通过 Pull Request / Merge Request
  • 必须获得负责人批准

Hotfix

用于存储即将发布的小版本更新。

命名格式：

Hotfix/版本号
例如：Hotfix/1.2.0

规则：

  • 所有修改必须通过 Pull Request / Merge Request
  • 必须获得负责人批准

Urgent

用于存储紧急版本更新。

命名格式：

Urgent/版本号
例如：Urgent/1.1.2

规则：

  • 所有修改必须通过 Pull Request / Merge Request
  • 必须获得负责人批准

Develop

用于在功能本地开发完成后进行集成测试。

规则：

  • 所有修改通过 Pull Request / Merge Request
  • 需要团队成员批准

说明：

由于该分支不是由负责人严格维护，如果仓库出现问题：

负责人可以：

  • 从最新版本重新拉取 或
  • 手动修复

Local

用于开发的短生命周期分支。

命名方式：

团队可自行决定，只要清晰易懂。

规则：

  • 从对应的 UAT / Hotfix / Urgent 分支创建
  • 根据功能要进入的版本决定

开发流程：

  • 所有 commit 在此分支完成
  • 功能完成后合并回对应版本分支
  • 需要定期从 UAT / Hotfix / Urgent 同步更新以避免冲突

合并流程

每次发布新版本后，需要进行分支合并以避免改动被覆盖。

一般规则：

将改动合并到所有更高版本的分支

例如：

1.1.2 < 1.2.0 < 2.0.0 < 3.0.0

Master / Review / Develop 的规则略有不同。

Main / Master

  • 不会被合并到其他分支
  • 只接受其他分支的合并

Review

当 Google Play Store 和 App Store 审核通过并正式发布后：

Review → Master

UAT

测试通过后：

如果不需要审核：

UAT → Master

如果需要审核：

UAT → Review

同时需要合并到更高版本的 UAT 分支

示例：

UAT/2.0.0 → UAT/3.0.0

Hotfix

测试通过后：

Hotfix → Master

同时需要合并到：

  • 所有 UAT 分支
  • 所有更高版本 Hotfix 分支

示例：

Hotfix/1.1.0 → Hotfix/1.2.0

Urgent

测试通过后：

Urgent → Master

同时需要合并到：

  • 所有 UAT 分支
  • 所有 Hotfix 分支
  • 所有更高版本 Urgent 分支

示例：

Urgent/1.1.1 → Urgent/1.1.2

Develop

  • 不会合并到其他分支
  • 仅用于开发人员进行集成测试

Local

短生命周期开发分支。

流程：

Local → UAT / Hotfix / Urgent

取决于该功能要进入哪个版本。

维护建议：

  • 定期从对应版本分支同步更新
  • 避免冲突

图示

版本发布后的合并顺序

flowchart LR
    A[Urgent/1.1.2] --> B[更高版本 Urgent 分支]
    A --> C[所有 Hotfix 分支]
    A --> D[所有 UAT 分支]
    A --> E[Master]

    F[Hotfix/1.2.0] --> G[更高版本 Hotfix 分支]
    F --> H[所有 UAT 分支]
    F --> I[Master]

    J[UAT/2.0.0] --> K[更高版本 UAT 分支]
    J --> L[Review（若需要审核）]
    J --> M[Master（若无需审核）]

分支体系概览

flowchart TB
  Master["Main / Master
线上公开版本"]
  Review["Review
审核中的主要版本（可选）"]

  subgraph ReleaseBranches["发布分支（按类型）"]
    direction TB
    UAT["UAT/x.y.z
主要版本候选"]
    Hotfix["Hotfix/x.y.z
小版本候选"]
    Urgent["Urgent/x.y.z
紧急版本候选"]
  end

  Develop["Develop
集成测试（可选）"]
  Local["Local/*
短生命周期开发分支"]

  UAT -->|"拉出开发分支"| Local
  Hotfix -->|"拉出开发分支"| Local
  Urgent -->|"拉出开发分支"| Local

  Local -->|"PR/MR 合并"| UAT
  Local -->|"PR/MR 合并"| Hotfix
  Local -->|"PR/MR 合并"| Urgent

  Urgent -->|"同步版本"| Hotfix
  Urgent -->|"同步版本"| UAT
  Hotfix -->|"同步版本"| UAT
  
  UAT -->|"可选：同步/合并到"| Develop
  Hotfix -->|"可选：同步/合并到"| Develop
  Urgent -->|"可选：同步/合并到"| Develop

  UAT -->|"无需审核：测试通过后合并"| Master
  UAT -->|"需要审核：测试通过后合并"| Review
  Review -->|"审核通过并发布后合并"| Master

  Hotfix -->|"测试通过后合并"| Master
  Urgent -->|"测试通过后合并"| Master

冲突解决

当在合并过程中遇到冲突时：

  1. 通知相关人员：
    • 冲突另一侧的作者
    • 项目负责人
  2. 如果是小问题且有信心解决：
    • 可以尝试自行解决
    • 但仍需要通知相关人员
  3. 如果是复杂问题：
    • 与另一侧作者协作解决
    • 确保不会破坏任何一方的功能
  4. 如果无法找到解决方案：

由 负责人最终决定处理方式

图示

冲突处理流程

flowchart TD
    A[发生合并冲突] --> B[通知相关人员<br/>冲突另一侧作者 + 负责人]
    B --> C{冲突是否简单<br/>且你有把握?}
    C -->|是| D[自行解决冲突]
    D --> E[通知相关人员：已解决方案与原因]
    C -->|否| F[与另一侧作者协作解决]
    F --> G{能否达成可行方案?}
    G -->|是| E
    G -->|否| H[由负责人最终决策解决方案]

潜在问题

1. 本地开发环境版本不同步

在使用 Local 分支进行开发时，开发者需要确保从各个仓库拉取的版本是同步的。

例如：

如果 config 仓库是在 server 仓库之后一周才拉取，则数据可能无法保持一致，从而导致一些不可预期的错误。

为了确保本地测试不会出现问题：

在进行测试之前，请确保所有相关仓库都已经合并到最新版本。

2. Git 无法自动解决的冲突

对于 Git 无法自动解决的冲突，需要由负责人来处理冲突。

如果在开发过程中遇到问题，可以将情况提出来讨论，以寻找最合适的解决方案。

不同仓库可能遇到的问题

不同类型的仓库，遇到冲突的概率和类型可能不同。

Art

发生冲突的可能性较低。

通常情况下不会遇到严重的合并问题。

Config

问题 1 和问题 2 都比较容易出现。

需要注意：

  • 问题 1：确保不同仓库之间的版本保持同步，以避免不必要的问题。

  • 问题 2：可以将一些在不同功能开发中经常需要修改的公共配置文件单独提取出来，并存放在文件存储服务器中统一管理。

当发生冲突时，负责人可以：

  • 从服务器拉取最新版本的文件

  • 用该版本来解决冲突

这样可以确保所有必要的修改仍然会保留在游戏中，同时减少配置冲突带来的问题。

如果这种方法在实际操作中存在困难，也可以再寻找其他方式来解决配置文件的冲突问题。

Client

问题 1 和问题 2 都可能发生。

需要注意：

  • 问题 1：确保仓库版本同步，避免不必要的问题

  • 问题 2：比较容易发生冲突的部分包括：

    • Scenes

    • Effects

这些问题可以通过提前规划修改内容来降低风险，避免多人同时修改相同内容。

Server

通常情况下：

  • 问题 1（版本不同步）较容易发生，需要注意避免。

对于 问题 2：

大多数情况下冲突可以通过以下方式解决：

  • Git 自动合并

  • 或者在稍微复杂的情况下，由负责人进行少量干预即可解决。

Proto

问题 1 和问题 2 都比较容易出现。

需要注意：

  • 问题 1：确保仓库版本同步，避免不必要的问题

  • 问题 2：大多数情况下冲突比较容易解决

但必须确保解决方式是正确的。

例如：

如果在 Resource enum 中：

Silver = 3
Gold = 3

那么相关开发人员需要协商决定哪一个需要修改为 4，以避免枚举值冲突。

典型工作流程：从规划到发布

规划阶段

  1. 各负责人之间进行讨论

  2. 规划项目时间线

  3. 项目经理创建新的 Milestone

  4. 项目经理将新的 Ticket 加入到该 Milestone 中

  5. 项目经理尽可能详细地填写 Ticket 的描述内容

开发阶段

  1. 策划开始进行功能设计
    更改 Ticket 状态为：Designer WIP

  2. 策划与开发人员和美术一起讨论该功能，以确认具体细节

  3. 策划整理并最终确认设计文档，并发布设计文档
    更改 Ticket 状态为：Designer Completed

  4. 美术根据设计文档开始制作相关资源
    更改 Ticket 状态为：Artist WIP

  5. 美术完成该功能所需的所有美术资源
    更改 Ticket 状态为：Artist Completed

  6. 开发人员根据设计文档和美术资源开始开发该功能
    更改 Ticket 状态为：Dev WIP

  7. 开发人员完成该功能的全部开发，包括美术资源与配置
    更改 Ticket 状态为：Dev Completed

  8. 策划确认该功能是否符合设计文档
    更改 Ticket 状态为：Designer Verified

  9. 美术确认该功能是否符合提供的美术样例
    更改 Ticket 状态为：Artist Verified

  10. 准备所有必要的 Merge Request，并等待所有相关仓库完成合并
    更改 Ticket 状态为：Ready To Test

  11. QA 开始对该功能进行测试
    更改 Ticket 状态为：Test In Progress

  12. QA 根据发现的问题创建新的 Bug Ticket
    更改 Ticket 状态为：Test Failed
    (如果没有问题则跳过此步骤)

  13. QA 确认该功能已完全完成并符合要求
    更改 Ticket 状态为：Test Completed

  14. 项目经理将改动部署到 **生产环境 更改 Ticket 状态为：Deployed

图示

功能生命周期概览

flowchart LR
  A[规划阶段] --> B[设计阶段]
  B --> C[制作阶段]
  C --> D[集成阶段]
  D --> E[测试阶段]
  E --> F[发布阶段]

  E -->|发现问题| C

按角色划分的详细工作流程

flowchart LR

  subgraph PM[项目经理]
    A[负责人讨论]
    B[规划时间线]
    C[创建 Milestone]
    D[创建 Ticket 并填写描述]
    Z[部署到生产环境 - 状态：Deployed]
  end

  subgraph Designer[策划]
    E[开始功能设计 - 状态：Designer WIP]
    F[与开发人员和美术讨论细节]
    G[完成设计文档 - 状态：Designer Completed]
    H[根据设计文档验证功能 - 状态：Designer Verified]
  end

  subgraph Artist[美术]
    I[开始制作美术资源 - 状态：Artist WIP]
    J[完成所有美术资源 - 状态：Artist Completed]
    K[验证美术实现是否正确 - 状态：Artist Verified]
  end

  subgraph Developer[开发者]
    L[开始功能开发 - 状态：Dev WIP]
    M[完成包含美术与配置的功能 - 状态：Dev Completed]
  end

  subgraph QA[测试]
    N[准备 Merge Requests - 状态：Ready To Test]
    O[开始测试功能 - 状态：Test In Progress]
    P{是否发现问题？}
    Q[创建 Bug Ticket - 状态：Test Failed]
    R[确认功能完成 - 状态：Test Completed]
  end

  A --> B
  B --> C
  C --> D
  D --> E
  E --> F
  F --> G
  G --> I
  I --> J
  J --> L
  L --> M
  M --> H
  H --> K
  K --> N
  N --> O
  O --> P
  P -->|是| Q
  Q --> L
  P -->|否| R
  R --> Z

典型工作流：从 Local 到发布

sequenceDiagram
  participant Dev as 开发者(Dev)
  participant Local as Local/*
  participant Rel as UAT/Hotfix/Urgent
  participant Review as Review(可选)
  participant Master as Master

  alt 开发
    Dev->>Local: 开发 & 提交 commits（只在 Local）
    Local->>Rel: 发起 PR/MR（Local -> 目标版本分支）
    Rel-->>Dev: Code Review / 修改建议
    Dev->>Local: 提交修复 commits（只在 Local）
    Local->>Rel: 更新 PR/MR（Local -> 目标版本分支）
  end

  alt 测试
    Rel-->>Rel: 测试
    Rel-->>Dev: 反馈问题（测试未通过）
    Dev->>Local: 回到 Local 修复并继续提交
    Local->>Rel: 推送更新（更新同一个 PR/MR）
    Rel->>Rel: 重新测试
  end

  alt 发布
    Rel->>Review: 合并（UAT -> Review）
    Review->>Master: 审核通过并发布后合并（Review -> Master）
  else 不需要审核（或 Hotfix/Urgent）
    Rel->>Master: 测试通过后合并（目标分支 -> Master）
  end