CKEditor5 发布工具中的 Git 预提交验证机制优化

在 CKEditor5 项目的持续集成和发布流程中，开发团队发现现有的发布工具存在一个潜在风险：当执行 dry-run（试运行）模式时，系统会跳过 Git 提交环节，导致无法触发预提交钩子（pre-commit hooks）中的静态代码分析工具（如 ESLint）。这一问题可能会让代码质量问题逃过检查，最终影响正式发布。

问题背景

CKEditor5 采用了一套自定义的发布工具链，其中包含 preparepackages 脚本，用于准备即将发布到 npm 的软件包。该脚本支持 dry-run 模式，在此模式下会生成包文件但不会实际影响代码仓库（不创建提交、不打标签等）。

原有的实现方式是通过 skip 回调函数来跳过提交阶段。虽然这种方法在大多数情况下有效，但它存在明显缺陷：跳过了关键的代码质量检查环节，特别是那些通过 Git 预提交钩子执行的检查。

技术挑战

开发团队在解决这个问题时面临几个技术难点：

1. 常用的 simple-git 库不支持直接传递 --dry-run 参数给 commit 命令
2. 即使使用原生 Git 的 --dry-run 选项，也不会触发预提交钩子
3. 需要确保解决方案既能执行完整的验证流程，又不会在 dry-run 模式下留下任何痕迹

解决方案演进

经过多次技术探讨和方案验证，团队最终确定了以下实现策略：

1. 实际提交方案：在 dry-run 模式下仍然创建真实的 Git 提交，以触发所有预提交钩子和验证流程
2. 状态回滚机制：提交成功后立即执行 git reset --soft HEAD~1 回滚操作，将仓库恢复到提交前的状态
3. 错误处理：如果验证失败导致提交未完成，则保持当前状态并报告错误

这种方案的优势在于：

• 能够完整执行所有预定义的代码质量检查
• 不会在 dry-run 模式下对仓库产生实际影响
• 提供真实的验证反馈，与正式发布时的环境完全一致

实现细节

在具体实现上，团队对 commitAndTag 函数进行了增强，使其能够：

1. 接收 dry-run 模式参数
2. 在 dry-run 模式下执行完整提交流程
3. 根据执行结果决定是否回滚提交
4. 提供清晰的执行日志和错误报告

影响范围评估

经过深入分析，团队发现这一改进主要影响以下两类项目：

1. 在发布过程中会修改源代码文件的项目（需要严格的代码质量检查）
2. 仅修改 package.json 等配置文件的简单项目（可保持原有逻辑）

因此，最终决定只在真正需要严格代码验证的项目中实施这一改进，避免不必要的复杂性。

技术价值

这一改进为 CKEditor5 生态系统带来了显著的技术价值：

1. 更高的代码质量保障：确保所有发布候选版本都经过完整的静态分析检查
2. 更可靠的发布流程：减少了因代码质量问题导致的发布后故障风险
3. 更透明的验证过程：开发人员可以提前在 dry-run 模式下发现潜在问题
4. 更一致的执行环境：dry-run 和实际发布的验证环境完全一致

这一技术改进体现了 CKEditor5 团队对代码质量和发布可靠性的高度重视，也为其他类似项目提供了有价值的技术参考。