Apache DolphinScheduler 提交代码全流程指南从 Fork 到 Pull Request 合并【免费下载链接】dolphinschedulerApache DolphinScheduler is the modern data orchestration platform. Agile to create high performance workflow with low-code项目地址: https://gitcode.com/GitHub_Trending/dol/dolphinschedulerApache DolphinScheduler 是一个现代数据编排平台社区贡献者通过 GitHub 的 Pull RequestPR流程将代码合入主干。本文以 docs/docs/zh/contribute/join/submit-code.md 为骨架完整讲解从 Fork 官方仓库、同步分支、编写代码、本地格式化到提交 PR 并通过 Code Review 的每一步操作。读完本文你将掌握 DolphinScheduler 贡献代码的完整链路并能一次性通过 CI 的代码风格检查Spotless避免因格式问题导致 PR 失败。前置准备理解 DolphinScheduler 的分支结构在动手之前先了解 DolphinScheduler 远端仓库upstream的分支策略这决定了你的代码应该提交到哪个分支分支类型说明master正常交付分支发布稳定版本后将稳定版本分支的代码合并到master上dev日常开发分支日常开发分支新提交的代码都可以 Pull Request 到这个分支branch-1.0.0发布版本分支发布版本分支后续还会有2.0等版本分支社区约定的通用规则是日常开发提交到dev分支。原文档中的branch-1.0.0属于历史示例实际仓库会随着版本迭代不断增加新的版本分支可以理解为当前版本号对应的发布分支。第一步Fork 代码到自己的仓库首先登录 GitHub打开 Apache DolphinScheduler 的官方仓库点击页面右上角的Fork按钮将代码复制一份到自己的 GitHub 账号下。Fork 出来的仓库称为你的origin仓库它是你后续推送代码的目的地。前置要求Fork 和提交 PR 都需要 GitHub 账号并在本机配置好 SSH Key 或 HTTPS 凭据。第二步Clone 代码到本地将你自己 Fork 的仓库克隆到本地git clone https://github.com/apache/dolphinscheduler.git如果使用 SSH 方式克隆命令为git clone gitgithub.com:apache/dolphinscheduler.git参见 docs/docs/zh/contribute/development-environment-setup.md。第三步添加远端仓库 upstream为了让本地仓库既能向自己的 Fork 推送origin又能拉取官方的最新代码需要把官方仓库添加为第二个远端命名为upstreamgit remote add upstream https://github.com/apache/dolphinscheduler.git查看仓库配置确认两个远端均已就位git remote -v此时应看到两个仓库origin你自己的仓库Fork 所得upstream官方远端仓库第四步获取并同步远端最新代码每次开发前都要确保本地基于官方dev分支的最新代码避免提交冲突。先拉取upstream的全部更新如果已经是最新代码可以跳过git fetch upstream将本地dev分支与远端dev分支同步git checkout origin/dev git merge --no-ff upstream/dev--no-ffno fast-forward会强制生成一个合并提交节点保留分支历史便于追溯同步来源。如果远端仓库新增了分支例如新增了dev-1.0需要把该分支同步到本地并建立追踪关系git checkout -b dev-1.0 upstream/dev-1.0 git push --set-upstream origin dev-1.0其中--set-upstream会将本地分支与远端origin/dev-1.0关联后续直接git push/git pull即可。第五步新建功能分支开发代码必须新建独立分支严禁直接在dev或master上修改。基于官方dev的最新代码创建分支git checkout -b xxx origin/dev确保分支xxx是基于官方dev分支的最新代码。分支命名建议遵循社区规范Pull Request 类型-Issue 号例如你想实现 Issue 111 对应的 Feature分支名应为Feature-111详见 docs/docs/zh/contribute/join/pull-request.md 中的分支名规范。第六步本地修改代码并执行 Spotless 格式化在新建分支上完成代码修改后提交前必须先执行项目统一格式化./mvnw spotless:apply这一步非常重要CI 会运行./mvnw spotless:check任何文件未格式化都会导致 PR 失败参见 docs/docs/zh/contribute/join/pull-request.md 中的 Pull Request Code Style 一节。Spotless 到底检查什么从仓库根目录的 pom.xml 可以确认 Spotless 的配置com.diffplug.spotless:spotless-maven-plugin版本 2.27.2其 Java 格式化规则包括Eclipse Formatter使用 style/spotless_dolphinscheduler_formatter.xml 定义的格式License Header使用 style/license-header 自动补齐文件头许可证声明Import Order使用 style/eclipse.importorder 强制 import 排序Remove Unused Imports自动移除未使用的 import禁用通配符导入通过replaceRegex移除import ...*;禁用指定依赖阻止引入org.powermock、非 Jupiter 的org.junit、io.kubernetes.client等不受欢迎的依赖。检查范围覆盖src/main/java/**/*.java、src/test/java/**/*.java以及 e2e/api-test 模块的 Java 文件pom.xml同时pom.xml的sortPom规则还会对 Maven 配置文件进行排序检查。把格式化嵌入提交前流程DolphinScheduler 还提供了pre-commit配置让你每次git commit前自动运行 Spotless 检查。安装方式需先安装 Pythonpython -m pip install pre-commit pre-commit install安装后每次提交代码时pre-commit都会自动运行 Spotless 检查代码风格和格式详见 docs/docs/zh/contribute/development-environment-setup.md。前端代码的风格检查如果你的改动涉及 dolphinscheduler-ui 前端代码还需要进入前端目录执行cd dolphinscheduler-ui pnpm run lint # 修复 ESLint 问题 pnpm run prettier # 格式化代码 pnpm exec vue-tsc --noEmit # TypeScript 类型检查详见 docs/docs/zh/contribute/development-environment-setup.md 的前端代码风格一节。第七步提交并推送到自己的仓库格式化通过后按社区规范提交 commit 并推送到自己的 Forkgit commit -m commit content git push origin xxx --set-upstreamCommit Message 规范要点DolphinScheduler 对 commit message 有严格要求详见 docs/docs/zh/contribute/join/commit-message.md格式为[Type-ISSUE_ID][Scope] Subject (可选 body —— 用要点列出主要改动) (可选 footer —— BREAKING CHANGE / Closes #xxx)Type必填Feature/Improvement/Fix/Doc/DSIP/Chore除Chore外都必须带上 Issue IDScope可选Master、Worker、API、UI、TaskPlugin、Dao等真实存在的模块名Subject必填祈使语气的简短句子控制 72 字符内句末不加句号。推荐示例[Fix-18201][TaskPlugin] Fix RemoteShell task NullPointerException on empty stdout不推荐示例fix bug、[fix] update master大小写不规范、缺 Issue ID、subject 含糊。第八步创建 Pull Request代码推送完成后前往 GitHub 仓库的 Pull Request 页面点击New pull request选择修改完的本地分支xxx和要合并的目的分支dev点击Create pull request提交。PR 标题规范PR 标题格式为[Pull Request 类型-Issue 号][模块名]Pull Request 描述类型与 Issue 类型的对应关系如下Issue 类型Pull Request 类型样例假设 Issue 号为 3333FeatureFeature[Feature-3333][server] Implement xxxBugFix[Fix-3333][ui] Fix xxxImprovementImprovement[Improvement-3333][alert] Improve the performance of xxxTestTest[Test-3333][api] Add the e2e test of xxxDocDoc[Doc-3333] Improve xxxE2EE2E[E2E-3333] Implement xxxCICI[CI] Improve xxxChoreChore[Chore] Improve xxx其中Issue 号指当前 PR 要解决的 Issue 号模块名与 Issue 的模块名保持一致详细表格见 docs/docs/zh/contribute/join/pull-request.md。PR 内容建议在 PR 描述中说明改动目的、实现思路与测试方案便于 Reviewer 理解。以下几点有助于加快合入先有 Issue再有 PR通常只有 Issue 被社区 approve 之后才需要有对应的 PR 去实现大功能建议先拆分为多个 Sub-Task 再逐个提交 PR参见 docs/docs/zh/contribute/join/issue.md保持 PR 最小粒度一个 PR 只做一件事Contributor 容易完成影响范围清晰对 Reviewer 压力小小步提交完成一个小功能就提交一次每次别改动太多文件避免给 Reviewer 造成心理压力。第九步Code Review 与合并PR 提交后社区 Committer 们会进行 Code Review与你讨论设计、实现、性能等细节。Review 中可能出现三种结果Approved代码无问题可以合并Commented提出修改建议需要你继续迭代Requested changes存在必须修复后才能合并的问题。当团队中所有人员对本次修改满意后Committer 会将提交合并到dev分支。如果 Review 过程中需要修改继续在你的分支上提交新 commit 并再次git push即可PR 会自动更新。延伸成为 DolphinScheduler 官方贡献者当你的第一个 PR 被合并后你就成为了 DolphinScheduler 的官方贡献者。此外还有更多参与方式修复 Bug 或实现 Feature领取 Issue 后先在 Issue 下回复表明你正在工作并为自己设置一个 deadline最好在核心贡献者中找一位导师获得即时反馈参见 docs/docs/zh/contribute/join/contribute.md新手建议从带有 easy to fix 标记或简单 Issue如拼写错误入手通过第一个简单的 PR 熟悉提交流程参与 Review任何人被鼓励去 Review 社区的 Issues 和 Pull Requests通过 Review 可以了解社区最新进展和他人代码的设计思想参见 docs/docs/zh/contribute/join/review.md非代码贡献帮助完善文档、增加测试用例、回答 Issue 问题、发表应用案例等都属于社区贡献参见 docs/docs/zh/contribute/join/contribute.md。常见问题与排错git merge --no-ff upstream/dev报冲突说明你的本地分支与官方dev有分叉解决冲突后提交合并结果即可CI 中spotless:check失败未执行./mvnw spotless:apply或格式化后有新增改动未提交回到本地重新执行格式化并提交PR 没有对应 Issue除Chore类型外PR/commit 都必须关联 Issue ID请先创建 Issue 再关联提交到错误分支日常开发请统一提交到dev确认 PR 的目的分支选择正确。【免费下载链接】dolphinschedulerApache DolphinScheduler is the modern data orchestration platform. Agile to create high performance workflow with low-code项目地址: https://gitcode.com/GitHub_Trending/dol/dolphinscheduler创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
