
人工智能计算机视觉深度学习【免费下载链接】mmcvOpenMMLab Computer Vision Foundation项目地址https://gitcode.com/gh_mirrors/mm/mmcv点击查看免费下载本指南面向希望为 OpenMMLab 计算机视觉基础库 MMCV 贡献代码的开发者完整梳理了从提交 issue、修复错误或新增组件到通过 pre-commit 检查、本地单元测试与 CI最终合入拉取请求PR的全流程。阅读并实践本文后你将能够独立完成一次规范的开源贡献正确复刻仓库、配置代码风格钩子、编写带类型注解的代码与单元测试并提交一份符合 MMCV 维护规范的 PR。参与贡献的三种方式与前置流程MMCV 欢迎任何类型的贡献官方将贡献分为三类每一类都给出了对应的推荐流程修复错误如果提交的代码改动较大建议先提交 issue并正确描述 issue 的现象、原因和复现方式讨论后确认修复方案修复错误并补充相应的单元测试提交拉取请求。新增功能或组件如果新功能或模块涉及较大的代码改动建议先提交 issue确认功能的必要性实现新增功能并添加单元测试提交拉取请求。文档补充修复文档可以直接提交拉取请求无需先开 issue添加文档或将文档翻译成其他语言则建议先提交 issue 确认必要性再添加文档并提交拉取请求。从仓库现状看中文社区文档目录 内的 pr.md 已注明本文档的内容已迁移到贡献指南说明贡献指南是社区协作流程的唯一权威入口而仓库根目录还维护着一份与本文内容一致的中英文贡献指南CONTRIBUTING_zh-CN.md 与 CONTRIBUTING.md供以仓库根目录为入口的贡献者阅读。拉取请求工作流从零开始提交第一个 PR如果你对拉取请求的协作模式还不熟悉下面按 7 个步骤完整演示一次 PR 的诞生过程。第 1 步复刻仓库第一次提交 PR 时需要先复刻 OpenMMLab 原代码库点击仓库页面右上角的Fork按钮复刻后的代码库会出现在你的个人主页下。将复刻得到的仓库克隆到本地{username}替换为你的 GitHub 用户名git clone gitgithub.com:{username}/mmcv.git然后添加原代码库为上游upstream代码库git remote add upstream gitgithub.com:open-mmlab/mmcv检查 remote 是否添加成功在终端输入git remote -v应看到类似输出origin gitgithub.com:{username}/mmcv.git (fetch) origin gitgithub.com:{username}/mmcv.git (push) upstream gitgithub.com:open-mmlab/mmcv (fetch) upstream gitgithub.com:open-mmlab/mmcv (push)这里需要理解origin与upstream的分工git clone时默认创建的origin指向你 fork 下来的远程仓库而upstream是你手动添加的、指向原始代码库的远程地址名字可以自定义例如open-mmlab。日常开发中我们通常向origin推送代码然后向upstream提交 PR如果提交的代码与最新代码冲突再从upstream拉取最新代码、在本地分支解决冲突后重新推送到origin。第 2 步配置 pre-commitMMCV 在本地开发环境使用 pre-commit 来统一代码风格。提交代码前需要先在 MMCV 目录下安装并激活钩子pip install -U pre-commit pre-commit install随后检查配置是否成功并安装 .pre-commit-config.yaml 中声明的全部钩子pre-commit run --all-files针对中国用户由于网络原因可能出现钩子安装失败的情况仓库为此提供了国内镜像版本配置 .pre-commit-config-zh-cn.yaml钩子来源替换为 Gitee 镜像改用如下命令即可pre-commit install -c .pre-commit-config-zh-cn.yaml pre-commit run --all-files -c .pre-commit-config-zh-cn.yaml如果安装过程被中断可以重复执行pre-commit run ...继续安装。当提交的代码不符合风格规范时pre-commit 会发出警告并自动修复部分错误如果想临时绕开检查提交一次代码可以在git commit时加上--no-verify但必须保证最终推送至远程仓库的代码能通过 pre-commit 检查git commit -m xxx --no-verify从仓库的 .pre-commit-config.yaml 可以看到MMCV 的钩子链相当完整validate_manifest、flake8、isort、yapf、trailing-whitespace、check-yaml、end-of-file-fixer、requirements-txt-fixer、double-quote-string-fixer、check-merge-conflict、fix-encoding-pragma、mixed-line-ending、codespell、mdformat、docformatter、pyupgrade、check-copyright检查mmcv、tests目录的版权头排除mmcv/ops以及mypy对tests与docs之外的文件做静态类型检查。其中mdformat还加载了mdformat-openmmlab等附加依赖确保 Markdown 文档的格式也遵循 OpenMMLab 约定。第 3 步创建开发分支安装完 pre-commit 后基于main分支创建开发分支建议的分支命名规则为username/pr_namegit checkout -b yhc/refactor_contributing_doc在后续开发中如果本地仓库的main分支落后于upstream的main分支需要先拉取 upstream 的代码进行同步再创建分支git pull upstream main第 4 步提交代码并在本地通过单元测试补充类型注解。MMCV 引入了 mypy 做静态类型检查以增加代码的鲁棒性因此提交代码时需要补充 Type Hints具体规则可参考仓库内 OpenMMLab 代码规范 中类型注解一节以及 .pre-commit-config.yaml 中 mypy 钩子的配置。通过单元测试。提交的代码必须通过测试# 通过全量单元测试 pytest tests # 运行修改模块的单元测试 pytest tests/test_cnn/test_wrappers.py原贡献指南以tests/test_runner/test_runner.py作为运行修改模块测试的示例以当前仓库为准tests 目录按模块组织为test_cnn/、test_image/、test_ops/、test_transforms/、test_utils/、test_video/等例如 tests/test_video/test_reader.py因此只需将命令中的路径替换为你所修改模块对应的测试文件即可。如果你由于缺少依赖无法运行修改模块的单元测试可参考下文 单元测试指引 安装所需依赖如果修改或添加了文档则参考 文档渲染指引 确认渲染正常。第 5 步推送代码到远程代码通过单元测试和 pre-commit 检查后将代码推送到远程仓库。如果是第一次推送可在git push后加上-u参数以关联远程分支git push -u origin {branch_name}这样后续就可以直接使用git push推送无需再指定分支和远程仓库。第 6 步提交拉取请求PR在 GitHub 的 Pull request 界面创建拉取请求根据指引修改 PR 描述以便其他开发者理解你的修改描述规范详见下文 拉取请求规范。提交 PR 时还需注意以下三点(a) PR 描述应包含修改理由、修改内容以及修改后带来的影响并关联相关 issue(b) 首次为 OpenMMLab 做贡献需要签署 CLA(c) 检查提交的 PR 是否通过 CI集成测试。关于 CIMMCV 会在不同平台Linux、Windows、Mac基于不同版本的 Python、PyTorch、CUDA 对提交的代码进行单元测试以保证正确性。仓库的 .github/workflows 目录下可以看到具体的流水线定义例如 lint.yml代码风格检查、pr_stage_test.ymlPR 阶段测试与 merge_stage_test.yml合入前测试。如果有任何一个任务没有通过可点击 CI 结果中的Details查看具体测试信息据此修改代码。如果 PR 通过了 CI就可以等待其他开发者的 review并根据 reviewer 的意见修改代码重复第 4~5 步本地测试、推送代码直到 reviewer 同意合入所有 reviewer 同意后维护者会尽快将 PR 合并到主分支。第 7 步解决冲突随着代码库不断更新你的 PR 可能随时间与主分支产生冲突解决方式有两种方式一rebasegit fetch --all --prune git rebase upstream/main方式二mergegit fetch --all --prune git merge upstream/main如果你非常善于处理冲突推荐使用 rebase 方式它能保证 commit log 的整洁如果对 rebase 不熟悉则使用 merge 方式即可。贡献指引单元测试与文档渲染单元测试指引如果你无法正常执行部分模块的单元测试例如 mmcv/video 模块很可能是当前环境缺少相应依赖例如视频模块依赖libturbojpeg与ffmpeg# Linux sudo apt-get update -y sudo apt-get install -y libturbojpeg sudo apt-get install -y ffmpeg # Windows conda install ffmpeg对应地tests/test_video 目录下的test_reader.py、test_optflow.py、test_processing.py覆盖了视频读取、光流与处理逻辑提交这些模块的改动前应确保相关依赖已安装并能跑通对应测试。在提交修复代码错误或新增特性的 PR 时应尽可能让单元测试覆盖所有提交的代码。计算单元测试覆盖率的方法如下python -m coverage run -m pytest /path/to/test_file python -m coverage html # check file in htmlcov/index.html运行后在htmlcov/index.html中查看覆盖率报告。文档渲染指引在提交修复代码错误或新增特性的 PR 时可能需要修改或新增模块的 docstring需确认渲染后的文档样式正确。本地生成渲染后文档的方法如下pip install -r requirements/docs.txt cd docs/zh_cn/ # 或 cd docs/en make html # check file in ./docs/zh_cn/_build/html/index.htmlrequirements/docs.txt 中锁定了文档渲染所需的依赖包括sphinx4.0.2、myst-parser、markdown、sphinx-copybutton、docutils、OpenMMLab 的pytorch_sphinx_theme等渲染完成后在docs/zh_cn/_build/html/index.html检查效果。注意由于文档系统采用 reStructuredText 语法docstring 中的:obj:、双反引号等标记会被 Sphinx 特殊解析在提交前最好生成并预览一次避免产生渲染错误。代码风格规范PythonPEP 8 与格式化工具链PEP 8 是 OpenMMLab 算法库首选的 Python 代码规范MMCV 使用以下工具检查和格式化代码flake8Python 官方发布的代码规范检查工具是多个检查工具的封装isort自动调整模块导入顺序的工具yapfGoogle 发布的代码格式化工具codespell检查单词拼写是否有误mdformat检查 Markdown 文件的工具docformatter格式化 docstring 的工具。yapf 和 isort 的配置可在 setup.cfg 中找到例如 yapf 基于pep8风格并开启split_before_expression_after_opening_parenisort 限定line_length 79、将mmcv设为 first-party 模块、按 OpenMMLab 惯例排布第三方库顺序addict, cv2, matplotlib, numpy, onnx, packaging, pytest, torch, torchvision, yaml, yapf等。此外 setup.cfg 中还包含 codespell 的ignore-words-list配置。通过配置 pre-commit hook可以在提交代码时自动检查和格式化 flake8、yapf、isort、trailing whitespaces、markdown files并修复 end-of-files、double-quoted-strings、python-encoding-pragma、mixed-line-ending 等问题还能自动调整requirements.txt中的包顺序。pre-commit 钩子的完整配置见 .pre-commit-config.yaml其安装使用方式见上文配置 pre-commit一节。更具体的代码规范命名规范、docstring 规范、注释规范、类型注解规范及 mypy 使用示例请参考 OpenMMLab 代码规范。C 与 CUDAMMCV 的算子大量涉及 C 与 CUDA 实现见 mmcv/ops 下按pytorch/cuda、pytorch/cpu等目录组织的算子源码其代码规范遵从 Google C Style Guide。当前仓库的 .pre-commit-config.yaml 中保留了一份被注释掉的clang-format本地钩子配置针对.c/.cc/.cpp/.cu/.h/.hpp/.cuh等文件、使用-stylegoogle可作为 C/CUDA 代码风格检查的参考实现思路。拉取请求规范为了让 PR 更容易被 review 并合入MMCV 对 PR 本身提出了六条硬性规范使用 pre-commit hook尽量减少代码风格相关问题一个 PR 对应一个短期分支粒度要细一个 PR 只做一件事情避免超大 PR。示例Bad实现 Faster R-CNNAcceptable给 Faster R-CNN 添加一个 box headGood给 box head 增加一个参数来支持自定义的 conv 层数每次 Commit 提供清晰且有意义的 commit 信息提供清晰且有意义的 PR 描述标题写明白任务名称一般格式[Prefix] Short description of the pull request (Suffix)prefix 约定新增功能[Feature]、修 bug[Fix]、文档相关[Docs]、开发中[WIP]WIP 状态暂时不会被 review描述里介绍 PR 的主要修改内容、结果以及对其他部分的影响可参考 PR 模板关联相关的 issue 和其他 PR如果引入了其他三方库或借鉴了三方库的代码请确认它们的许可证与 MMCV 兼容并在借鉴的代码上补充This code is inspired from http://...形式的来源说明。仓库在 .github/pull_request_template.md 提供了标准 PR 模板包含 Motivation动机、Modification修改内容、BC-breaking是否破坏下游向后兼容性、Use cases新特性使用场景以及 PR 前后 Checklist是否遵循 CONTRIBUTING 工作流、是否通过 lint、bug 是否覆盖单元测试、文档是否同步更新、是否已签署 CLA、是否需要在下游 MMDet/MMCls 等项目上验证影响提交 PR 时按模板填写即可。仓库内相关资源一览.pre-commit-config.yamlpre-commit 钩子完整配置flake8、isort、yapf、codespell、mdformat、mypy、check-copyright 等.pre-commit-config-zh-cn.yaml面向中国用户的 Gitee 镜像版配置setup.cfgyapf、isort、codespell 风格配置docs/zh_cn/community/code_style.mdOpenMMLab 代码规范详解命名、docstring、注释、类型注解.github/pull_request_template.md标准 PR 描述模板.github/workflows/lint.yml 与 .github/workflows/pr_stage_test.ymlCI lint 与 PR 阶段测试流水线requirements/docs.txt文档渲染依赖清单CONTRIBUTING_zh-CN.md 与 CONTRIBUTING.md仓库根目录维护的贡献指南内容与本指南一致docs/zh_cn/community/pr.md旧版 PR 文档内容已迁移至本贡献指南。赞分享人工智能计算机视觉深度学习【免费下载链接】mmcvOpenMMLab Computer Vision Foundation项目地址https://gitcode.com/gh_mirrors/mm/mmcv点击查看免费下载相关推荐Pest 贡献指南从 Fork 到合入的完整开发工作流Pest 贡献指南从 Fork 到合入的完整开发工作流 本文是 Pest优雅的 PHP 测试框架仓库的贡献指南详解面向希望参与 Pest 核心开发、提交测试Flower 贡献工作流实战从 Fork 仓库到合并第一个 PR 的完整指南Flower 贡献工作流实战从 Fork 仓库到合并第一个 PR 的完整指南 本文基于 Flower 官方文档《Contribute on GitHub》整理人工智能联邦学习机器学习深度学习Chaos Mesh 贡献指南从 Fork 到合入 PR 的完整开发流程Chaos Mesh 贡献指南从 Fork 到合入 PR 的完整开发流程 本文是 Chaos MeshA Chaos Engineering Platfor云原生运维测试可观测性上一篇Mantle源码中的宏技巧MTLMetamacros实现编译时反射下一篇从手绘风格到3D模型a-picture-is-worth-a-1000-words项目视觉风格演变创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考