Git 方法论
概述
详细介绍了用于 RAPIDS 的 Git 分支方法以及 Git 提交的风格规范。
目标受众
社区
开发者
另请参阅
Git 分支
方法
我们的开发方法包括保护 main 分支，使其成为任何 RAPIDS 项目的官方发布记录。开发 PR 将合并到发布分支，该分支仅在发布准备就绪时才会合并到 main 并打上标签。main 分支的其他合并仅限于热修复。
开发流程
所有 PR 都合并到一个名为 branch-M.B 的发布分支，其中 M 是主版本号，B 是次版本号。发布分支是在决定冻结发布时从上一个发布分支创建的。
冻结发布分支意味着停止该版本的新开发，并将重点放在完成未完成的功能和测试中发现的任何错误上。一旦发生冻结，将创建一个新的分支 branch-M.C（其中 C=B+1），以便继续开发。branch-M.B 的更新可以根据需要合并到 branch-M.C，但通常会等到发布完成后。这意味着 branch-M.X（其中 X 是最高的次版本号）包含最新和最好的代码。
与当前版本 M.A 相关的热修复（补丁版本）直接从 PR 合并到 main，然后这些更改也会通过自动化流程合并到当前正在进行的发布分支。所有合并到 main 的操作都会触发一个自动化 CI 作业，该作业将生成一个新的版本并打上标签，补丁版本号会基于仓库中前一个最高标签递增。一旦设置了标签，conda 包的自动化 CI 构建将为用户创建并推送新的包。这包括版本更改，从而支持已知良好的构建并具备回滚能力。
次要版本（以及最终的主要版本）开发在当前发布分支上进行。可以在 GitHub 上编辑 PR，以设置 PR 合并的目标基础分支。审阅者有责任确保 PR 的目标是正确且计划好的发布分支。一旦 PR 通过所有测试，它们将被合并到其发布分支，这将触发 conda 包的自动化 CI 构建，这些包将被标记为开发版本，例如 M.N-dev1。团队可以检查这些包，以确保构建按预期工作并进行更大的测试。
一旦版本经过审阅并获得批准，就会创建一个 PR 将发布分支合并到 main。合并后，自动化标记过程将标记并发布一个次要版本，并启动面向公众发布的 conda 构建。
总结
- 的
main分支是官方发布历史（包括热修复）。- 鉴于已合并 PR 的测试和审阅，
main的最新提交应始终处于可用状态。 - 每次推送到
main时，热修复（补丁版本）都会自动打上标签。
- 鉴于已合并 PR 的测试和审阅，
- 发布分支用于下一个版本的开发，并且除热修复之外的所有 PR 都合并到当前发布分支。
- 在版本冻结后（见上文），会从之前的发布分支创建一个新的发布分支。
- 冻结后且发布分支合并前，存在两个发布分支；然而，活跃开发应在新版本分支中进行，而清理和最终确定则在冻结分支中进行。
- 这样，编号最高的
branch-M.X（排除热修复和未合并的冻结版本修复）就拥有了最新最好的代码。
- 次要版本通过从相关的发布分支为次要版本创建 PR 来完成。
- 经团队审阅并批准后，该 PR 将合并到 main。
大文件与 Git
任何大于 5MB 的文件必须使用 Git LFS 或 S3 存储。
| 大小 | 必需 | 非必需 |
|---|---|---|
| <5MB | Git | Git |
| >5MB | Git LFS | S3 |
| >2GB | 避免 | S3 |
一个 必需 文件是指普通开发者构建和/或测试项目所需的 文件。这可能包括用于运行单元测试的小型数据集或大型源文件。
一个 非必需 文件应存储在 S3 中，这样只有少数需要它们的开发者才能“选择”下载这些更大的文件。这有助于为大多数用户保持仓库较小。
从一开始就选择适当的存储机制非常重要，因为从 Git 过渡到 Git LFS 或 S3 需要重写 Git 历史。
如果您需要将数据上传到 S3，只需提交一个运维 (Ops) 问题。