媒体生成计算机视觉深度学习人工智能大模型【免费下载链接】mmagicOpenMMLab Multimodal Advanced, Generative, and Intelligent Creation Toolbox. Unlock the magic : Generative-AI (AIGC), easy-to-use APIs, awsome model zoo, diffusion models, for text-to-image generation, image/video restoration/enhancement, etc.项目地址https://gitcode.com/gh_mirrors/mm/mmagic点击查看免费下载MMagicMultimodal Advanced, Generative, and Intelligent Creation Toolbox是 OpenMMLab 旗下的多模态生成式 AI 工具箱覆盖文本生成图像、图像/视频修复增强、图像补全、抠图等众多 AIGC 应用场景。本文以 MMagic 官方社区贡献指南为主线系统讲解从 Fork 仓库、配置 pre-commit、提交单元测试到最终发起 Pull Request 的完整协作闭环并结合仓库内的.pre-commit-config.yaml、setup.cfg、CI 工作流与tests/目录结构为你提供一套可直接落地的开源贡献工程实践。读完本文你将掌握 MMagic 的代码风格基线、测试与文档规范以及一条不会踩坑的 PR 提交流程。一、MMagic 社区与贡献方式总览MMagic 社区致力于构建多模态高级生成与智能创作工具箱。正如 docs/en/index.rst 所描述的该项目基于 PyTorch支持无条件/条件 GAN、内部学习、扩散模型等基础生成模型并覆盖 Text-to-Image、图像超分、视频超分、视频插帧、图像补全、图像抠图、图像修复、图像上色等丰富应用。社区欢迎所有类型的贡献包括但不限于以下三类修复 Bug代码或文档中的笔误可以直接提交 Pull Request 修正。若改动涉及较深层的实现问题建议先创建 Issue 描述报错信息与触发方式与开发者讨论确定合理方案后再提交 PR并补充对应的单元测试。新特性或增强涉及较大改动的特性应先创建 Issue 与开发者讨论设计实现新特性/增强后提交 PR并附带对应单元测试。文档文档修正可直接提交 PR若要新增一篇文档应先创建 Issue 确认其合理性避免文档体系的无序膨胀。二、Pull Request 完整工作流七步走如果你对 Pull Request 尚不熟悉不必担心下面按官方指南的七个步骤逐步拆解每一步都对应真实的仓库配置作为验证依据。1. Fork 并克隆仓库首次提交 PR 时需要先在 GitHub 页面右上角点击Fork按钮将 OpenMMLab 的仓库复制到自己的账号下。随后将 fork 得到的仓库克隆到本地git clone gitgithub.com:{username}/mmagic.git克隆完成后将官方仓库添加为 upstream 远端git remote add upstream gitgithub.com:open-mmlab/mmagic用git remote -v验证是否添加成功正常应看到四条记录origin gitgithub.com:{username}/mmagic.git (fetch) origin gitgithub.com:{username}/mmagic.git (push) upstream gitgithub.com:open-mmlab/mmagic (fetch) upstream gitgithub.com:open-mmlab/mmagic (push)理解 origin 与 upstream 的分工是后续协作的关键git clone默认创建指向所克隆仓库的originupstream是手动添加、指向目标官方仓库的远端命名可自定义。日常开发将代码推送到origin当推送的代码与官方最新代码冲突时从upstream拉取最新代码解决冲突再重新推送到origin已提交的 Pull Request 会自动更新。2. 配置 pre-commitpre-commit 是 OpenMMLab 系列仓库统一采用的代码风格闸门确保提交的代码风格与社区基线一致。注意以下命令必须在 mmagic 目录下执行pip install -U pre-commit pre-commit install执行pre-commit run --all-files可验证配置是否生效并安装.pre-commit-config.yaml中定义的全部钩子pre-commit run --all-files仓库根目录的 .pre-commit-config.yaml 是这套钩子体系的真实清单从中可以看到 MMagic 实际启用的检查与格式化工具含各工具版本flake8rev 4.0.1围绕多种 linter 的包装器执行代码风格与基础错误检查isort5.12.1自动排序 import 语句yapfv0.30.0Google 出品的 Python 格式化器pre-commit/pre-commit-hooksv3.1.0包含 trailing-whitespace、check-yaml、end-of-file-fixer、requirements-txt-fixer、double-quote-string-fixer、check-merge-conflict、fix-encoding-pragma--remove、mixed-line-ending--fixlf等通用钩子codespellv2.1.0修正文本中的常见拼写错误跳过*.ipynb并忽略特定词表mdformat0.7.9Markdown 格式化器配合--number、--table-width 200以及 mdformat-openmmlab、mdformat_frontmatter、linkify-it-py 等插件docformatterv1.3.1docstring 格式化--in-place --wrap-descriptions 79本地钩子 update-model-index当configs/下的.md文件变更时自动运行.dev_scripts/update_model_index.py收集模型信息并更新model-index.ymlopen-mmlab/pre-commit-hooksv0.4.0check-algo-readme、check-copyright作用于demo、mmagic、tests、tools目录、remove-improper-eol-in-cn-docs本地钩子 update-model-zoo通过docs/en/.dev_scripts/update_model_zoo.py维护模型动物园清单。如果代码不符合风格规范pre-commit 会给出警告并自动修复部分错误安装过程若被中断可重复执行pre-commit run ...继续安装。若确需临时绕过钩子提交仅限临时提交可使用git commit -m xxx --no-verify对于受网络问题影响、无法从默认源下载钩子的中文用户官方指南提供了 Gitee 镜像配置pre-commit install -c .pre-commit-config-zh-cn.yaml pre-commit run --all-files -c .pre-commit-config-zh-cn.yaml3. 创建开发分支配置好 pre-commit 后应基于 main 分支创建开发分支建议分支命名为username/pr_namegit checkout -b yhc/refactor_contributing_doc后续开发过程中如果本地 main 分支落后于 upstream 的 main需要先同步再创建分支git pull upstream main4. 提交代码并通过单元测试提交前需满足两个硬性要求类型检查MMagic 引入 mypy 做静态类型检查以提升代码健壮性因此新代码需要添加 Type Hints 并通过 mypy 检查不熟悉 Type Hints 可参考 Python 官方 typing 文档。单元测试提交的代码必须通过单元测试官方给出的命令为# 运行全部单元测试 pytest tests # 运行指定测试模块 pytest tests/test_engine/test_runner/test_multi_loops.py从仓库结构看tests/ 目录按被测对象划分为test_apis、test_datasets、test_engine含test_hooks、test_optimizers、test_runner、test_schedulers、test_evaluation含test_functional、test_metrics、test_models含test_archs、test_base_models、test_data_preprocessors、test_diffusion_schedulers、test_editors、test_losses、test_utils、test_structures、test_utils、test_visualization与 setup.cfg 中testpaths tests/的 pytest 配置一一对应。例如 runner 相关测试实际位于 tests/test_engine/test_runner/包含test_log_processor.py、test_loop_utils.py、test_multi_loops.py等文件可用上述命令单独运行验证。若单元测试因缺少依赖而失败可参照下文单元测试与覆盖率一节安装依赖。若修改/新增了文档还需按下文文档渲染一节的指引检查渲染结果。5. 推送代码到远端通过单元测试与 pre-commit 检查后即可将本地提交推送到远端。通过-u选项将本地分支与远端分支关联git push -u origin {branch_name}此后可直接使用git push推送无需再指定分支与远端。6. 创建 Pull Request1在 GitHub 的 Pull request 界面创建 PR。2按规范撰写 PR 描述使其他开发者能快速理解改动内容具体规范见下文PR 规范一节。3PR 描述与流程上还有三点注意事项(a) PR 描述应包含改动原因、改动内容与改动影响并关联相关 Issue(b) 若是首次贡献请签署 CLA(c) 检查 PR 是否通过 CI。MMagic 会对提交的 PR 在不同平台Linux、Windows、Mac、不同 Python、PyTorch、CUDA 版本组合下运行单元测试以验证正确性。点击 CI 面板中的Details可查看具体测试信息并据此修改代码。仓库中 .github/workflows/pr_stage_test.yml 展示了这套机制的实现PR 触发时在ubuntu-22.04上构建 CPU 环境安装指定版本 PyTorch/torchvision如 2.0.1/0.15.2、MMEngine、MMCV安装requirements/tests.txt依赖后执行pip install -e .再以coverage run --branch --source mmagic -m pytest tests/运行全量单元测试并生成覆盖率报告上传至 Codecov工作流同时声明了对README.md、docs/**、configs/**等路径的忽略避免纯文档/配置改动触发全量测试。4PR 通过 CI 后等待其他开发者 review。根据评审意见修改代码重复步骤 4–5提交测试、推送远端直到所有 reviewer 批准随后 PR 会被尽快合入。7. 解决冲突若本地分支与 upstream 最新 main 分支冲突有两种解决方式git fetch --all --prune git rebase upstream/main或git fetch --all --prune git merge upstream/main官方建议擅长处理冲突时优先使用rebase可以保持提交日志整洁对rebase不熟悉时使用merge解决冲突。三、配套开发指导Guidance单元测试与覆盖率提交的代码不应降低单元测试覆盖率官方提供如下检查命令python -m coverage run -m pytest /path/to/test_file python -m coverage html # 在 htmlcov/index.html 中查看覆盖率报告这与 CI 中coverage run --branch --source mmagic -m pytest tests/的做法同源帮助你在本地提前复现 CI 的覆盖率检查结果。文档渲染若修改/新增了文档需要检查渲染结果。先安装文档依赖再执行 Sphinx 构建pip install -r requirements/docs.txt cd docs/zh_cn/ # 或 cd docs/en make html # 在 ./docs/zh_cn/_build/html/index.html 中查看渲染结果requirements/docs.txt 锁定了文档构建依赖版本如sphinx4.5.0、docutils0.16.0、myst_parser、pytorch_sphinx_theme、sphinx-copybutton、sphinx-notfound-page、sphinx-tabs、sphinx_markdown_tables、sphinx-autoapi等docs/en/conf.py 中启用了intersphinx、napoleon、viewcode、autosectionlabel、myst_parser等扩展并将../../mmagic设为 autoapi 的扫描目录同时定义BUILDDIR _build见 docs/en/Makefile与上述命令中的输出路径完全对应。四、代码风格规范Python 风格MMagic 采用PEP8作为首选代码风格并使用以下工具进行 lint 与格式化flake8多种 linter 的包装器isort排序 import 的 Python 工具yapfPython 格式化器codespell修正文本常见拼写错误mdformat强制 Markdown 风格一致的格式化器docformatterdocstring 格式化器。yapf 与 isort 的风格配置可在仓库根目录的 setup.cfg 中找到其关键配置包括[yapf]段基于pep8风格、blank_line_before_nested_class_or_def true等[isort]段设置line_length 79、known_first_party mmagic并预置了PIL, cv2, lmdb, mmcv, numpy, onnx, onnxruntime, packaging, pymatting, pytest, pytorch_sphinx_theme, requests, scipy, titlecase, torch, torchvision, ts等第三方库分组[flake8]段因 yapf 冲突忽略 E251并对*/__init__.py的 F401、mmagic/configs/*的 F401/F403/F405/E501 做了 per-file 豁免。pre-commit 钩子在每次提交时自动执行flake8、yapf、isort检查与格式化并处理 trailing whitespaces、markdown 文件、文件末尾空行end-of-file、双引号字符串、python-encoding-pragma、混合行尾mixed-line-ending同时自动排序requirements.txt。钩子配置即上文展示的 .pre-commit-config.yaml。C 和 CUDAC/CUDA 代码遵循Google C Style Guide。五、PR 规范PR Specs官方对 PR 本身提出了五条硬性规范使用 pre-commit 钩子规避代码风格问题一个短周期分支只对应一个 PR保持分支与改动一一对应一个 PR 完成一个具体改动避免过大的 PR。官方给出的粒度示例BadSupport Faster R-CNN范围过大AcceptableAdd a box head to Faster R-CNN可接受的模块级改动GoodAdd a parameter to box head to support custom conv-layer number理想的参数级改动提供清晰且有意义的提交信息commit message提供清晰且有意义的 PR 描述标题应明确任务名称通用格式为[Prefix] Short description of the PR (Suffix)Prefix 约定新特性[Feature]、修 Bug[Fix]、文档相关[Docs]、开发中[WIP]WIP 暂不进入评审简短描述中说明主要改动、结果及对其他模块的影响关联相关 Issue 与 Pull Request 至同一个 milestone。六、CI 流水线对贡献者的实际意义除了 .github/workflows/pr_stage_test.yml 的多平台/多版本单元测试矩阵仓库还提供了 .github/workflows/lint.yml 作为代码质量闸门该工作流在 push 与 pull_request 时触发安装 pre-commit 后执行pre-commit run --all-files做全量风格检查并通过 interrogate 校验 docstring 覆盖率--fail-under 90。这意味着贡献者的 PR 不仅要通过单元测试还要在提交前就通过完整的 pre-commit 检查链否则 CI 会直接亮红灯。综合来看MMagic 的贡献流程是一个本地 pre-commit 单元测试 → 远端 CI 多平台矩阵 → reviewer 评审的三层质量体系。只要严格遵循本文梳理的七步工作流、代码风格规范与 PR 规范并善用pytest tests、coverage、make html等本地验证手段就能以最低的沟通成本提交高质量 PR顺利融入 MMagic 社区的开源协作。赞分享媒体生成计算机视觉深度学习人工智能大模型【免费下载链接】mmagicOpenMMLab Multimodal Advanced, Generative, and Intelligent Creation Toolbox. Unlock the magic : Generative-AI (AIGC), easy-to-use APIs, awsome model zoo, diffusion models, for text-to-image generation, image/video restoration/enhancement, etc.项目地址https://gitcode.com/gh_mirrors/mm/mmagic点击查看免费下载相关推荐XGo 贡献指南从 Fork 到 Pull Request 的完整协作流程与提交规范XGo 贡献指南从 Fork 到 Pull Request 的完整协作流程与提交规范 本文以 XGo 官方贡献指南 https://link.gitcode.编程语言编译器开发工具Fluentd GitHub 贡献工作流实战指南从 Fork 到 Pull Request 的完整协作流程Fluentd GitHub 贡献工作流实战指南从 Fork 到 Pull Request 的完整协作流程 Fluentd 是一款 CNCF 旗下的统一日志采日志分析可观测性后端MMPose 贡献指南从 Fork 到 Pull Request 的完整开源协作流程MMPose 贡献指南从 Fork 到 Pull Request 的完整开源协作流程 MMPose 是 OpenMMLab 团队开源的姿态估计工具箱与基准库计算机视觉人工智能深度学习上一篇【亲测免费】 开源项目 OpenH264 安装与使用指南下一篇Stable Video Infinity与Nuke集成电影级视觉效果制作工作流终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考