前言昇腾CANN在AtomGit上开源了55个仓库代码贡献者来自华为内部、高校、企业。这么多人在同一个项目里写代码如果没有治理规范仓库很快就会乱掉——commit message五花八门、代码风格不统一、未签协议的代码混入。community和cann-agreements这两个仓库就是昇腾CANN社区的治理基础设施。community定义了贡献流程和评审规则cann-agreements管理贡献者许可协议CLA。一个PR从提交到合并这两个仓库的规则贯穿始终。这篇会把一个PR的完整生命周期拆清楚从Fork到Merge每一步该做什么、容易踩什么坑。社区治理体系两个仓库的分工仓库职责核心内容community流程治理贡献指南、评审规则、行为准则、Issue模板cann-agreements法律治理CLA文本、签署流程、贡献者名单CLA贡献者许可协议CLA是开源社区的入场券。签了CLA意味着你同意你的贡献遵循项目的开源协议Apache 2.0。不签CLAPR直接被机器人关掉。昇腾CANN的CLA分两种个人CLA个人贡献者签署企业CLA企业代表签署员工的贡献由企业协议覆盖PR完整生命周期1. 签署CLA 2. Fork仓库 → 创建分支 3. 开发 测试 4. 提交PRcommit message规范 5. CI自动检查 6. Reviewer审查 7. Maintainer合并第1步签署CLA# 访问CLA签署页面# https://atomgit.com/cann/cann-agreements# 点击Sign Individual CLA# 用AtomGit账号OAuth授权# 签署完成后你的AtomGit ID会被记录到贡献者名单签署后机器人会在你的PR下评论✅ CLA check passed. Thank you for signing the Contributor License Agreement.第2步Fork仓库 → 创建分支# Fork目标仓库到自己的账号# 在AtomGit页面点击Fork按钮# 克隆你的Forkgitclone https://atomgit.com/your-username/ops-math.gitcdops-math# 创建特性分支命名规范类型/简短描述gitcheckout-bfeat/add-philox-random-engine# 分支命名规范# feat/xxx → 新功能# fix/xxx → Bug修复# docs/xxx → 文档更新# refactor/xxx → 重构第3步开发 测试# 以给ops-math添加Philox随机数引擎为例# 新增文件ops-math/random/philox_kernel.cpp# 编写代码遵循昇腾CANN代码规范# ...省略具体实现# 编写测试必须有测试无测试的PR不会被接受# test_philox.pyimporttorchimportops_mathdeftest_philox_basic():测试Philox引擎的基本功能# 生成1000个随机数rngops_math.PhiloxRNG(seed42)xrng.uniform(shape[1000],low0.0,high1.0)assertx.shape(1000,)assert0.0x.min()x.max()1.0print(✅ 基本功能测试通过)deftest_philox_reproducibility():测试相同种子的可复现性rng1ops_math.PhiloxRNG(seed42)rng2ops_math.PhiloxRNG(seed42)x1rng1.uniform(shape[1000])x2rng2.uniform(shape[1000])asserttorch.allclose(x1,x2),相同种子应该产生相同的随机数序列print(✅ 可复现性测试通过)if__name____main__:test_philox_basic()test_philox_reproducibility()代码讲解测试代码要覆盖功能正确性和边界条件。test_philox_basic验证基本shape和值域test_philox_reproducibility验证相同种子生成相同序列。没有测试的PR会被Reviewer直接要求补充。第4步提交PR# 添加改动gitaddops-math/random/philox_kernel.cpp test_philox.py# 提交遵循Conventional Commits格式必须有-s签名gitcommit-s-mfeat(random): add Philox parallel random number engine Implement Philox RNG based on counter-based PRNG design. Supports parallel generation with independent counters per core. Performance: 100M random numbers in 0.3s (vs NumPy 6s). Closes #123# 推送到Forkgitpush origin feat/add-philox-random-enginecommit message格式规范type(scope): subject body Closes #issue-numbertype含义feat新功能fixBug修复docs文档refactor重构test测试chore构建/工具代码讲解-s参数自动添加Signed-off-by:行这是DCODeveloper Certificate of Origin要求。Closes #123会在PR合并时自动关闭对应的Issue。subject行不超过50字符body详细描述改动内容和原因。第5步CI自动检查提交PR后CI机器人自动执行以下检查检查项工具失败后果DCO签名DCO bot❌ 直接拒绝CLA签署CLA bot❌ 直接拒绝代码格式clang-format / black❌ 要求修复编译CANN CI❌ 要求修复测试pytest / CTS❌ 要求修复代码安全安全扫描⚠️ 人工复查CI结果会显示在PR页面✅ DCO check passed ✅ CLA check passed ✅ Code format check passed ✅ Build check passed ✅ Test check passed (42/42 passed)第6步Reviewer审查CI通过后Maintainer会指定Reviewer。Reviewer按以下维度审查维度关注点功能正确性逻辑是否正确边界是否处理性能是否有性能回归代码风格是否符合项目规范测试覆盖测试是否充分文档是否更新了相关文档Reviewer会在代码行内评论# 典型的Review评论 ❓ 这里用FP16会不会有精度问题建议加个FP32的fallback。 → 回复已添加FP32 variant见commit abc1234 这个循环可以用向量化替代性能提升约3倍 → 回复好建议已修改第7步Maintainer合并Reviewer批准后通常需要至少1个LGTMMaintainer执行合并# Maintainer操作在AtomGit Web界面# 1. 确认CI全部通过# 2. 确认至少1个LGTM# 3. Squash and Merge压缩为1个commit# 4. 合并后自动删除分支合并后贡献者会收到邮件通知贡献记录出现在项目的贡献者列表中。踩坑实录坑1未签CLAPR被机器人秒关现象提交PR后1分钟内被关闭机器人评论“Please sign the CLA before submitting.”原因CLA必须先签后提交。先提交再补签机器人不会自动重新检查。解决先签CLA再提交PR。如果已经提交了签完CLA后关闭旧PR重新开一个。# 签署CLA# 访问 https://atomgit.com/cann/cann-agreements → Sign CLA# 签完后重新提交gitcommit--amend-sgitpush-forigin feat/add-philox-random-engine# 关闭旧PR创建新PR坑2commit message没有Signed-off-byDCO检查失败现象CI报错DCO check failed: Commit does not have Signed-off-by.原因git commit时忘了加-s参数。解决修改最后一个commit的签名。# 补上签名gitcommit--amend-s# 强制推送因为修改了历史gitpush-forigin feat/add-philox-random-engine坑3一个PR包含多个不相关改动被要求拆分现象Reviewer要求Please split this PR into separate ones for each feature.原因PR里同时改了算子实现、修了文档typo、加了个新测试——三个不相关的改动混在一个PR里增加了Review难度和回滚风险。解决一个PR只做一件事。# 错误一个PR包含3个不相关改动gitcommit-s-mfeat: add Philox fix typo add test# 正确拆成3个独立PR# PR1: feat(random): add Philox engine# PR2: docs: fix typo in README# PR3: test(random): add Philox unit tests结尾昇腾CANN的社区治理体系由community和cann-agreements两个仓库支撑定义了从CLA签署到PR合并的完整流程。核心规则先签CLA、commit格式规范、一个PR只做一件事、必须有测试。如果想在昇腾CANN开源社区贡献代码建议先从文档修复和小bugfix入手熟悉流程后再提交功能PR。实测下来从Fork到合并规范提交的PR平均3-5天合并不规范的PR要来回改2-3周。昇腾CANN的开源社区还在持续完善治理流程。如果在贡献过程中遇到啥问题欢迎去AtomGit上的昇腾CANN开源社区逛逛里面有一手资料和活跃社区。社区链接https://atomgit.com/cann/communityhttps://atomgit.com/cann/cann-agreements
