修改大型多语言数据平台单体仓库，并准备拉取请求

## 第一次编辑前，确认Git远程仓库并选对分支 在会话中进行第一次编辑或测试之前： 1. 确认个人分叉仓库和作为权威来源的上游远程仓库；如果其角色不明确，请求配置标准的远程仓库布局； 2. 检查上游默认分支的时间戳，并在本地引用过旧时刷新该引用； 3. 检查工作树，并在切换上下文之前要求用户保护未提交的更改； 4. 根据任务选择分支。 对于现有审查，解析其head分支；如果存在匹配的本地分支，则使用该分支并报告切换情况。如果没有匹配项，询问是获取该分支，还是使用名称不同的本地分支。对于新的编辑，推荐提供一个以上游默认分支为起点的隔离worktree，也可以基于该分支新建分支。对于仅测试的工作，使用上游默认分支。 ## 重新生成测试的参考输出和协议文件，而不是手动修改 golden测试输出属于生成它们的测试框架。在运行或更新这些输出之前阅读测试套件文档，绝不直接编辑生成的预期结果文件，并通过受支持的工作流重新生成它们。接受结果前，仔细审查生成的差异。 协议定义属于其模式源。在更改消息或字段之前，阅读与这些定义存放在一起的文档，并且不要把生成的协议制品纳入手工编辑。 ## 在CI之前，让代码保持ASCII并遵守每行长度限制 除非字符串字面量或测试夹具的内容确实需要其他字符，否则标识符、代码和注释都应使用ASCII。抽查更改过的文件中是否存在排版破折号、弯引号、省略号和不换行空格；这些字符经常在不经意间进入注释。 将源代码行控制在仓库限制以内，该限制通常为100个字符。对新增和修改的源文件进行快速扫描时，可以粗略排除import、package声明和URL，但这种扫描只提供提示。各语言专用的linter仍是最终依据。 ## 选择刚好够用的最小JVM测试基类 选择能够提供所需行为的最小测试基类。普通运行时测试或实用工具测试应使用核心套件，其中只包含通用的超时、临时文件、日志和错误辅助工具。逻辑计划、分析器、优化器或规划器测试应使用计划测试基类，并且不启动SQL会话。 SQL或表测试应使用查询测试基类，并混入显式的会话提供器。普通SQL测试选择进程内会话；只有在需要数据仓库行为时，才选择由数据仓库支持的提供器。不要仅仅因为附近的测试使用了范围更广的夹具，就承担该夹具的额外成本。 ## 为本地、远程和混合Python测试选择合适的测试基类 普通Python测试应使用标准单元测试基类。上下文级测试可以为每项测试创建新的执行上下文以实现隔离，也可以为每个类复用一个上下文以提高速度。SQL和DataFrame测试应使用共享的classic会话基类，而DataFrame扩展测试可以增加列式执行和专用断言。 远程协议测试需要单独判断：不需要服务器时，使用仅处理计划的mock夹具；需要真实远程行为时，使用复用的远程会话；需要检查一致性时，使用结合classic与remote的夹具。除非SQL实用工具、结构化错误断言和相等性辅助工具会创建所需的运行时，否则应将它们视为mixin或独立辅助工具，而不是测试基类。 ## 只构建和测试改动的模块，运行完整套件前先询问 构建和测试的成本可能很高。如果用户明确要求测试，就运行测试。否则，在开始耗时的完整套件验证之前，先询问是否还会进行更多编辑。优先使用仓库中速度更快的增量构建工具，只编译受影响的模块及其测试代码，并在迭代过程中运行单个套件或指定名称的测试用例。 如果保持增量构建shell处于打开状态可以缩短反复执行模块测试的时间，就不要关闭它。对于依赖已构建后端的Python套件，先构建所需的功能配置，再激活用户选择的虚拟环境或文档规定的默认环境；仅在该环境不存在时才创建它。使用项目测试运行器的套件选择器和用例选择器。 ## 修复任何一项之前，先列出所有失败的CI检查 在调查任何一项失败之前，先列出审查提交中失败的每项检查。测试摘要检查通过或不存在，并不能证明CI全部通过；linter、许可证、依赖项、兼容性检查、编译和文档构建可能会在没有测试注释的独立任务中失败。 对于测试任务，使用失败注释获取套件、用例和消息。对于非测试任务，确定失败的步骤并阅读聚焦于该任务的日志。如果结构化注释已经包含有用证据，应避免下载非常庞大的分片测试日志。 ## 确认显示为已关闭的拉取请求其实是否已合并 不要认定标记为已关闭的审查就是被拒绝了。有些项目通过自定义工具进行合并，因此托管服务可能会把成功合并的审查显示为已关闭，并且没有原生的合并时间戳。 使用项目的合并状态辅助工具，确定更改是否已纳入，以及哪些主分支或维护分支包含该更改。把开放、已合并和关闭但未合并视为不同结果，并将缺少身份验证、浅层历史、未知审查或缺少上游远程仓库报告为环境限制。 ## 按项目的规范写拉取请求的标题和说明 遵循项目针对issue标识符和组件标签的标题规范，其中包括文档规定的草稿、进行中、轻微或琐碎更改的例外情况。根据差异推断标题。如果缺少必需的issue，通过项目辅助工具创建它，准确指定组件，并指定issue类型或引用的父项；然后醒目地显示已创建的issue及其字段，以供审查。 在起草说明之前阅读仓库的拉取请求模板，并填写每个部分。如果issue跟踪器要求使用完整组件名称，而不是缩写的标题标签，则使用完整名称。 ## 只向自己的分叉仓库push，对外写入前先征得同意 绝不向作为权威来源的上游仓库push；只能向贡献者的分叉仓库push。除非用户明确要求，否则不要对已存在于远程仓库的提交执行force-push或amend。如果远程分支已有新的进展，在push之前先fetch并rebase。 在执行外部写入之前取得明确批准，包括push提交、创建拉取请求、创建issue或发表评论。使用项目支持的已认证客户端。如果该客户端不可用，应准备审查URL或准确的交接说明，而不是绕过必需的工作流。 ## 使用最先发布该更改的分支的版本号 当代码需要版本注释、配置版本或兼容性排除项时，使用最先发布该更改的分支版本，并去掉snapshot后缀。对于以维护分支为基础的审查，使用该分支的版本。 对于以主分支为基础的审查，如果更改通常会回移到最新发布分支，则使用最新发布分支的版本。只有工作仅适用于主分支时才使用主分支版本，例如破坏性更改、二进制不兼容更改，或者不值得进行关键回移的依赖项升级。如果发布路径不明确，应当询问，而不能仅根据主分支进行推断。 ## 报告安全问题前，先阅读项目的安全策略 在报告安全问题之前，先阅读该仓库的安全策略和威胁模型。确认其中声明的适用范围、明确排除的情况，以及文档认定不构成安全问题的情形，以便按照项目实际提供的保证来评估扫描器结果。 将安全调查与普通缺陷分类工作分开，完整保留相关证据，并且在记录安全发现时不要暴露凭据或敏感的本地数据。