可观测性APM链路追踪指标监控日志分析微服务【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址https://gitcode.com/gh_mirrors/sk/skywalking点击查看免费下载Apache SkyWalking 是一个开源的 APMApplication Performance Monitoring系统其官方代码仓库的.claude/skills/gh-pull-request/SKILL.md为 AI 编码助手Claude Code定义了一套完整的 PR 分支工作流在每次提交与推送前执行编译、Checkstyle、License 头与全限定类名FQCN审计等预检随后按项目规范提交推送、创建 PR并在合并后完成分支同步与清理。本文以该文档为主体结合仓库中的 checkstyle 配置、PR 模板、License 头模板 与 CI 工作流系统讲解这套流程的每一步帮助贡献者掌握可被合并的 SkyWalking 提交流程。工作流总览整套 PR 分支工作流可分为四个阶段文档将其定义为PR Branch Workflow预检Pre-flight checks每次commit push之前运行包括编译与 Checkstyle、License 头检查、全限定类名审计提交与推送Commit and push预检通过后按分支策略提交并推送创建 PRCreate PR若当前分支尚无 PR则按仓库模板创建合并后清理After the PR is merged同步默认分支并删除本地特性分支。这套流程的核心思想是把质量把关前置到推送之前确保 CI 与评审者看到的第一版代码就已通过项目的基本质量门禁。预检一编译与 Checkstyle两条预检命令文档要求在每次提交推送前执行以下两条命令# Checkstyle ./mvnw -B -q clean checkstyle:check # Full build (compile javadoc) ./mvnw clean flatten:flatten install javadoc:javadoc -B -q -Pall \ -Dmaven.test.skip \ -Dcheckstyle.skip \ -Dgpg.skip-B批处理非交互模式适合 CI 与自动化场景-q安静模式只输出错误与关键信息flatten:flatten执行 flatten-maven-plugin将多模块工程的复杂 POM 扁平化为发布用 POMinstall将构件安装到本地仓库验证所有模块可构建javadoc:javadoc生成 Javadoc验证注释格式与{link}引用的有效性-Pall激活全部 profile保证所有可选模块都被编译验证-Dmaven.test.skip跳过测试执行预检阶段只验证编译-Dcheckstyle.skip跳过 Checkstyle第一条命令已单独执行过-Dgpg.skip跳过 GPG 签名。仓库中的 Checkstyle 配置依据SkyWalking 的 Checkstyle 规则集中在 apm-checkstyle/checkStyle.xml根 POM 中通过maven-checkstyle-plugin版本3.1.0见 pom.xml 的maven-checkstyle-plugin.version属性引用该文件并设置了configLocation指向${maven.multiModuleProjectDirectory}/apm-checkstyle/checkStyle.xmlincludeTestSourceDirectory为true测试代码同样受规则约束failOnViolation由属性checkstyle.fails.on.error控制默认true即一旦违规构建即失败。checkStyle.xml中值得注意的全局规则Checker级禁止源码中出现System.out.printlnRegexpSingleline禁止author版权注释ASF 项目规范禁止中文字符出现在代码文件中单个文件长度上限 3000 行FileLength。TreeWalker级与 import 相关的规则包括UnusedImports、RedundantImport、AvoidStarImport这正与预检三的全限定类名审计形成互补Checkstyle 负责检查 import 的冗余与通配而 FQCN 审计负责捕获 Checkstyle 抓不到的内联全限定名。预检二License 头检查检查命令license-eye header check若发现无效文件先修复再复检license-eye header fixlicense-eyegithub.com/apache/skywalking-eyes是 SkyWalking 使用的 License 头检查工具它依据仓库根目录的 HEADER 模板逐文件校验 Apache License 2.0 头。SkyWalking 的 CI 工作流 .github/workflows/skywalking.yaml 中也包含license-headerjob通过go install github.com/apache/skywalking-eyes/cmd/license-eye...安装固定版本后执行检查与本地预检保持一致。为什么检查 License 头作为 Apache 顶级项目SkyWalking 要求每个源码文件包括.java、.xml、.yaml等都以 Apache License 2.0 头开头。仓库根目录 HEADER 中定义的标准模板如下Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to You under the Apache License, Version 2.0 ...新增文件时若漏掉 License 头license-eye header check会将其标记为无效文件此时执行header fix可自动补齐但修复后应重新运行 check 确认全部通过再进入提交阶段。预检三全限定类名FQCN审计规则背景项目 Checkstyle 禁止内联全限定类名——代码中的每个类型引用都应通过import解析而不是直接写出java.util.HashMap这样的全限定名。文档特别指出Checkstyle 并不总能抓住这类问题例如内联java.util.HashMap内联java.util.concurrent.TimeUnit将org.apache.skywalking.oap.server.telemetry.api.HistogramMetrics.Timer用作局部变量类型、泛型参数或new目标。因此推送前需要用 Grep 工具ripgrep对分支改动的文件做一次额外审计。扫描模式文档给出的扫描模式如下注意它依赖负向前瞻BSDgrep不支持需使用 ripgrep 或 GNUgrep -Ppattern: ^(?!\s*(import |package |\s*\*)).*\b(java\.util\.|java\.io\.|java\.nio\.|java\.util\.concurrent\.|javassist\.|org\.apache\.skywalking\.)[A-Z][A-Za-z0-9_]* glob: *.java output_mode: content -n: true该模式通过^(?!\s*(import |package |\s*\*))排除 import 语句、package 语句与注释行再匹配以java.util.、java.io.、java.nio.、java.util.concurrent.、javassist.、org.apache.skywalking.开头的内联类型引用。扫描范围只扫分支改动的文件文档强调将扫描范围限定在分支实际改动的文件上避免整棵代码树中历史遗留的 FQCN 产生噪音。获取改动文件列表git diff --name-only master...HEAD -- *.java然后对列表中的每个文件运行上述 ripgrep 模式。允许的例外与 CLAUDE.md 的规则一致以下三种情况是允许的例外两个类同名、同时 import 会冲突时Javadoc{link}中短名称对读者有歧义时字符串字面量内部例如传给Class.forName的类名字符串。除此之外的所有命中都必须修复——增加import并改用短名称。字段声明、方法签名、局部变量、泛型类型参数都应使用 import 后的短名称包括new java.util.HashMap()和java.util.SetString参数类型这类写法。修复后的隐患Range 越界错误文档特别提醒修复时如果使用粗糙的sed/replace_all可能损坏import行本身——例如把import java.util.concurrent.locks.ReentrantLock;错误地替换成import ReentrantLock;。这种损坏不会报普通的 Checkstyle 违规而是抛出令人困惑的Range [0, -1) out of bounds for length N错误。看到该错误时应首先检查 import 块。修复完成后需要重新运行 Checkstyle第一条预检命令确认。提交与推送预检全部通过后进行提交与推送git add files git commit -m message git push -u origin branch-name分支策略文档明确规定绝不直接在 master 分支上工作若当前处于 master先创建新分支git checkout -b feature/name # 或 git checkout -b fix/name分支名按用途区分feature/前缀用于新功能fix/前缀用于缺陷修复。这与仓库的 CI 工作流和评审习惯相呼应也便于 PR 标题与模板归类。创建 Pull Request检查 PR 是否已存在gh pr view --json number 2/dev/null如果当前分支已有 PR此命令会输出其编号若没有命令失败则创建新 PR。PR 标题标题需简洁概括改动内容文档给出示例Fix BanyanDB query timeout issueAdd support for OpenTelemetry metricsPR 描述严格遵循仓库模板文档强调必须阅读 .github/PULL_REQUEST_TEMPLATE 并使用其精确格式与复选框不得使用自定义摘要格式。仓库模板将 PR 分为三类对应不同的勾选项缺陷修复Bug Fixes### Fix bug description or issue link - [ ] Add a unit test to verify that the fix works. - [ ] Explain briefly why the bug exists and how to fix it.新功能New Features### Feature description - [ ] If this is non-trivial feature, paste the links/URLs to the design doc. - [ ] Update the documentation to include this new feature. - [ ] Tests(including UT, IT, E2E) are added to verify the new feature. - [ ] If its UI related, attach the screenshots below.性能改进Performance Improvements### Improve the performance of class or module or ... - [ ] Add a benchmark for the improvement. - [ ] The benchmark result. - [ ] Links/URLs to the theory proof or discussion articles/blogs.所有 PR 都必须包含- [ ] If this pull request closes/resolves/fixes an existing issue, replace the issue number. Closes #issue number. - [ ] Update the [CHANGES log](https://link.gitcode.com/i/96e7559dd1b031b647ab7499fe4b5a5a).模板中的Always include部分体现了 SkyWalking 的硬性要求关联 issue 编号Closes #number以及更新 CHANGES 日志——仓库在docs/en/changes/目录下按版本维护changes.md及changes-X.Y.Z.md各版本记录这是每次合入代码都必须同步维护的变更清单。创建命令gh pr create --title title --body $(cat EOF PR body from template EOF )使用 heredoc 将模板正文传入--body可避免引号转义问题。创建后动作添加copilot作为评审者gh pr edit number --add-reviewer copilot不要将 AI 助手添加为共同作者co-author代码责任由提交者承担完成后返回 PR 链接。PR 合并后的同步与清理PR 合并后需要同步默认分支并清理特性分支。文档给出四步操作# 1. Prune stale remote refs. GitHub auto-deletes the PRs branch on merge, so # the remote feature branch is usually already gone; --prune removes the # dangling local tracking ref. git fetch origin --prune # 2. Switch back to the default branch and fast-forward it to include the merge. git checkout master git pull --ff-only origin master # 3. Confirm the change actually landed in master before deleting anything — # git log --oneline -1 should show the merge/squash commit with the PR # number, or grep for a symbol the PR introduced. git log --oneline -1 # 4. Delete the local feature branch. SkyWalking SQUASH-merges PRs, so the # feature branchs commit is NOT an ancestor of master (master gets a new # squash commit instead). git branch -d therefore reports not fully # merged — that is expected, not an error. After confirming the content is # in master (step 3), force-delete: git branch -d branch 2/dev/null || git branch -D branch关键注意事项Squash 合并导致git branch -d报 not fully merged 是正常现象SkyWalking 的 PR 采用 SQUASH 合并master 上生成的是全新的 squash 提交SHA 与特性分支提交不同因此特性分支的提交不是 master 的祖先。第 3 步确认改动确实合入后使用-D强制删除即可第 3 步不可跳过强制删除一个实际未合入的本地分支会永久丢失工作。确认方式可以是git log --oneline -1显示的合并提交带 PR 编号也可以 grep PR 引入的某个符号若远端分支未被自动删除取决于仓库设置需显式删除git push origin --delete branchgit pull --ff-only保证 master 以快进方式更新避免产生意外的合并提交。总结把流程沉淀为可执行清单结合文档与仓库源码SkyWalking 的 PR 分支工作流可沉淀为如下执行清单切分支绝不直接在 master 上工作使用feature/或fix/前缀编译 Checkstyle./mvnw -B -q clean checkstyle:check与完整构建命令规则见 apm-checkstyle/checkStyle.xmlLicense 头license-eye header check模板见 HEADERCI 同款校验见 .github/workflows/skywalking.yamlFQCN 审计用 ripgrep 对git diff --name-only master...HEAD -- *.java列出的文件扫描内联全限定名修复后重跑 Checkstyle警惕Range [0, -1) out of bounds提示 import 块被损坏提交推送git add→git commit→git push -u origin branch创建 PR先gh pr view判重标题简洁正文严格套用 .github/PULL_REQUEST_TEMPLATE 的复选框格式Bug Fix / New Feature / Performance Improvement 三类并附带Closes #issue与 CHANGES 日志 更新项创建后添加copilot评审合并后清理git fetch origin --prune→git checkout master git pull --ff-only→git log --oneline -1确认合入 →git branch -d失败时squash 合并属正常确认后git branch -D删除。这套工作流既适合人类贡献者手工执行也适合 AI 编码助手在提交 PR 前自动完成质量门禁其核心价值在于把所有可能在评审与 CI 阶段暴露的问题提前到第一次推送之前解决。赞分享可观测性APM链路追踪指标监控日志分析微服务【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址https://gitcode.com/gh_mirrors/sk/skywalking点击查看免费下载相关推荐tldraw 仓库 Pull Request 创建与更新完整工作流从分支准备到评审提交pr / write-pr 技能指南tldraw 仓库 Pull Request 创建与更新完整工作流从分支准备到评审提交pr / write pr 技能指南 导读 本文基于 tldraw前端UI组件NumPy 开发工作流指南从创建 feature 分支到提交 Pull Request 的完整 Git 实践NumPy 开发工作流指南从创建 feature 分支到提交 Pull Request 的完整 Git 实践 本文以 doc/source/dev/devel科学计算数据分析ESLint 贡献指南从创建分支到合并提交一个高质量 Pull Request 的完整流程ESLint 贡献指南从创建分支到合并提交一个高质量 Pull Request 的完整流程 ESLint 是一个基于 AST 的 JavaScript 模式开发工具Lint静态分析代码质量上一篇react-redux-starter-kit中的React性能优化shouldComponentUpdate使用指南下一篇Python-PCL终极3D点云处理解决方案完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
