# 版本控制 在游戏中，版本控制将按照以下规则进行格式化： ## 命名规则 ### 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 ### 图示 版本号升级规则: ```mermaid 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 取决于该功能要进入哪个版本。 维护建议： - 定期从对应版本分支同步更新 - 避免冲突 ## 图示 版本发布后的合并顺序 ```mermaid 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（若无需审核）] ``` 分支体系概览 ```mermaid 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. 如果无法找到解决方案： 由 **负责人最终决定处理方式** ### 图示 冲突处理流程 ```mermaid flowchart TD A[发生合并冲突] --> B[通知相关人员
冲突另一侧作者 + 负责人] B --> C{冲突是否简单
且你有把握?} 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** ### 图示 功能生命周期概览 ```mermaid flowchart LR A[规划阶段] --> B[设计阶段] B --> C[制作阶段] C --> D[集成阶段] D --> E[测试阶段] E --> F[发布阶段] E -->|发现问题| C ``` 按角色划分的详细工作流程 ```mermaid 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 到发布 ```mermaid 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 ```