参与 RE-UE4SS 贡献
感谢你抽出时间参与贡献!项目欢迎并重视各种形式的贡献。本指南介绍参与项目的流程和规范。
目录
报告问题
如果仍需帮助:
- 使用正确的模板创建 Issue。
- 尽可能详细地提供问题发生时的上下文。
- 提供项目和平台版本(操作系统等)。
- 如果问题与构建有关,提供工具链信息(编译器版本等)。
- 只要有
UE4SS.log,就请附上,即使它看起来没有帮助。
安全问题: 切勿在公开问题跟踪器中报告安全问题、漏洞或包含敏感信息的缺陷。请把敏感问题通过电子邮件发送至 security@ue4ss.com。
Pull Request 规范
基本要求
- 提交 PR 前,确保至少在以下版本中测试过修改:
- 一个 4.11 至 4.25 之间的 Unreal Engine 版本(4.25 是
UProperty被FProperty替代的版本)。 - 一个 4.25 之后的版本,最好是 UE 5.1 或更新版本。
- 一个 4.11 至 4.25 之间的 Unreal Engine 版本(4.25 是
- 所有 PR 必须包含:
- 清晰的修改说明。
- 待修复问题的复现步骤(如适用)。
- 能复现所修问题或演示新增功能的代码。
- 相关测试用例或示例。
- 对 Changelog.md 的相应更新。
- 代码应有充分文档,并遵循仓库现有的风格约定。
开发流程
- Fork 仓库。
- 为功能或缺陷修复创建新分支。
- 实现修改。
- 运行与修改相关的测试。
- 必要时更新文档。
- 提交 Pull Request。
代码风格规范
UEPseudo 代码
-
UEPseudo 中的代码应遵循 Unreal Engine 的格式和风格约定。
-
直接实现 Unreal Engine 源码时,保持原有风格。
-
对原 UE 代码的任何偏离或修复,必须放在以下注释之间:
// RE-UE4SS FIX (Contributor initials or username): [explanation of why the fix is needed] // Modified code goes here // RE-UE4SS FIX END
注释中应填写贡献者姓名缩写或用户名,以及需要修复的原因;修改后的代码置于两条标记之间。
主仓库代码
- 主仓库的所有代码在提交前必须运行
clang-format。 - 遵循仓库现有代码风格以保持一致。
- 使用有意义的变量名和函数名。
- 为复杂逻辑或不直观的实现添加注释。
提交消息规范
-
所有提交消息优先采用 Conventional Commits 格式:
<type>[optional scope]: <description> [optional body] [optional footer(s)] -
常见类型有
feat、fix、docs、style、refactor、test、chore。 -
适用时在提交消息中引用 Issue 编号。
-
每次提交只聚焦一个逻辑修改。
升级规范
项目维护升级指南,用于记录不兼容变更,帮助用户在版本之间迁移。
面向贡献者
API 发生不兼容变更时:
- 必须在
/docs/upgrade-guide.md中记录所有不兼容变更,包括:- 变更内容的清晰说明。
- 变更原因。
- 对比旧写法与新写法的代码示例。
- 特殊迁移步骤。
- 不兼容变更应遵循以下原则:
- 尽量减少对已有代码的影响。
- 尽可能在移除功能前提供弃用警告。
- 考虑向后兼容或提供过渡 API。
- 通过版本编号清晰传达变更,并遵循语义化版本规范。
- 提交包含不兼容变更的 PR 时:
- 在 PR 标题中明确标记
breaking-change。 - 在 Changelog 中增加“Breaking Changes”小节。
- 在升级指南中引用该 PR。
- 在 PR 标题中明确标记
面向 API 用户
/docs/upgrade-guide.md包含逐版本的迁移说明。- 每个主版本和次版本都有专门章节说明变更。
- 更新到新版本前,务必阅读升级指南。
- 指南包含适配 API 变更的代码示例。
升级指南按时间倒序排列,最新版本位于顶部,便于逐步升级。
许可证
RE-UE4SS 许可证
参与 RE-UE4SS 贡献,即表示同意将贡献内容以 MIT 许可证发布。
UEPseudo 代码许可
UEPseudo 代码受 Epic Games 的许可条款约束。
感谢你帮助改进 RE-UE4SS!
来源致谢
本指南基于 contributing.md 编写。
原文:docs/contributing.md · 固定提交 560411f18512 · 来源与 MIT 许可