Table of Contents

neo-bpsys-wpf 开发文档

软件框架和技术栈：

框架：.Net 9.0.4 WPF

UI库：WPF-UI

IOC容器：Microsoft.Extensions.DependencyInjection

动画库：XamlFlair.WPF

拼音库：hyjiacan.pinyin4net

MVVM部分：CommunityToolkit.Mvvm

下载器: Downloader

开发工具

Visual Studio 2022、Jetbrains Rider，使用Rider时提交需排除.idea文件夹

IDE插件需要

Xaml Styler

命名规范

类Class、属性Property、方法Mothods 统一采用大驼峰命名法upper camel case

字段Field 统一采用_+小驼峰命名法lower camel case

与游戏名词相关的术语

Ban 禁用
Pick 选择
Sur 求生者
Hun 监管者
Camp 阵营
Talent 天赋
Trait 辅助特质
Game 对局，单独出现时是单个游戏对局，在GameProgress中是指一个回合
Character/Chara 角色
Map 地图
GameProgress 对局进度，如Game1FirstHalf 第一局上半场
Team 队伍
Main 主队
Away 客队
Member 队伍成员
Player 选手（包含Member）
OnField 已上场
Score 比分
Win 胜
Lose 负（前台的好像用不着了）
Tie 平
MinorPoint 小比分
MajorPoint 大比分
Front 前台（bp展示界面）
Interlude 过场画面，展示阵容和天赋
GameData 赛后数据

禁用Ban的部分统一采用动词在前如BanHun（禁用监管者），其余均为名词在前的命名比如（SurPick求生者选择）

Commit 提交规范

类型(作用域):

内容，如果是bug fix，说明解决方案

类型和作用域可以有多个，逗号+空格隔开，可以只写对应功能Page/Window的名称或者对应模块的名称，如：BanHunPage、DesignMode

Example:

refactor(Timer, DesignMode):

计时器获取改为Messenger通知改变，IsDesignMode变化由原来的事件通知改为Messenger通知

类型 说明
feature 新功能
fix 修复bug
refactor 重构
docs 改文档，例如README
style 代码风格改变，不影响功能
temp 临时提交，用于合作开发
chore 杂项，例如.gitignore、github workflow
build 更改构建脚本、构建工具
revert 回滚
merge 合并
improve 提升

版本号迭代原则

首位仅在出现大型重构或又非常重大更改时（如官方规则改变、UI重构）才会跟进

第二位出现重大的新Module更新/第三位满十才会跟进

第三位是有新Feature就会跟进

最后一位自动生成，用于BugFix和Improvement版本，不用手动迭代

仓库分支管理流程规范

1. 分支结构说明

• main 分支：主分支，存放稳定发布版本，仅通过 PR 合并更新

• dev 分支：开发主分支，存放最新开发代码，基于 main 分支创建

• feature 分支：功能开发分支，基于 dev 分支创建，开发完成后合并至 dev

2. 主版本更新流程（dev 合并至 main）

2.1. 提交 PR 合并 dev 到 main

  • 在 GitHub 上创建从 dev 到 main 的合并请求（PR）
  • 确保 PR 通过代码审查后，点击 Merge pull request 合并
  • 合并方式选择 Create a merge commit（默认方式）

2.2. 自动同步 dev 分支

  • PR 合并后，GitHub Action 自动触发以下操作： git checkout dev && git rebase main
  • （注：此步骤由 CI 工具自动完成，无需手动操作）

2.3. 本地更新 dev 分支

  • 本地切换到 dev 分支：
git checkout dev git pull  # 拉取远程 dev 分支（已自动 rebase 到 main）
  • 继续在 dev 上进行后续开发

3. 小 bug 修复流程（直接在 dev 上修改）

3.1. 更新本地 dev 分支

git checkout dev
git pull --rebase  # 拉取远程更新并变基，保持本地分支整洁

3.2. 修复 bug 并提交

  • 修改代码
  • 提交
git add . git commit -m "fix: 修复具体 bug 描述"

3.3. 推送到远程 dev 分支

git push origin dev

4. 新功能开发流程（基于 feature 分支开发）

4.1. 在 Microsoft Todo 上新增条目并分配给自己

4.2. 拉取最新 dev 分支

git checkout dev
git pull --rebase

4.3. 创建 feature 分支

git checkout -b feature/功能名称

4.4. 开发功能并提交

开发过程中可多次提交，提交信息需清晰描述改动：

git add .
git commit -m "feat: 功能模块-具体功能描述"

4.5. 同步最新 dev 分支

git checkout dev
git pull --rebase
git checkout feature/功能名称
git rebase dev  # 将 feature 分支变基到最新 dev，解决冲突

4.6. 压缩提交并合并到 dev

压缩 feature 分支的所有提交为一个 commit

git checkout dev
git merge --squash feature/功能名称
git commit -m "feat: 完整功能描述"  # 编写统一的提交信息

4.7. 推送到远程 dev 分支并清理

git push origin dev
git branch -d feature/功能名称  # 删除本地 feature 分支
git push origin --delete feature/功能名称  # 删除远程 feature 分支

4.8. 在 Microsoft Todo 上勾选对应完成的 feature

5. 注意事项

5.1. 提交规范

  • 使用语义化提交格式（如 feat:、fix:、docs: 等前缀）
  • 提交信息需清晰描述改动目的，避免模糊表述

5.2. 分支维护

  • dev 分支需定期与 main 同步（通过主版本更新流程自动完成）
  • 废弃的 feature 分支需及时删除，保持仓库整洁

5.3. 冲突处理

  • 变基（rebase）过程中遇到冲突时，需手动解决后执行 git rebase --continue
  • 合并（merge）时优先使用变基方式，保持线性提交历史
Edit this page