跨分支迁移审计工具

要解决什么问题

长期分叉的两个分支往往已经不能直接 git merge：你要迁的是一整块目录，或一个散落在多目录、多 commit 里的功能。手工翻 log、猜 cherry-pick 顺序，很容易漏掉「模块外」的强依赖 commit，或在 build.gradle、strings.xml 这类文件上踩 CR 行尾、签名不一致、目标分支独有代码被覆盖等坑。

技能如何工作

本技能在迁移前做预审计，支持三种输入：模块路径（目录扫描）、功能模式（commit 列表 / 关键词 / 时间+作者 / Issue ID 等多策略交叉验证）、混合模式（路径 + 关键词补模块外改动）。

典型流程包括：自动识别项目类型与多渠道结构 → 确定 commit 范围 → 标记涉及迁移范围外文件的 commit → 按 diff 与语言习惯（import、#include、use 等）区分强/弱/基础设施/测试/资源依赖 → 对外部文件做冲突风险分级 → 检查行尾、签名差异、传递依赖、构建配置等通用陷阱 → 输出 HTML 交互报告（概览、风险面板、强依赖列表、文件风险矩阵、迁移策略与 cherry-pick 后检查清单）。

报告会给出分层迁移建议、建议 cherry-pick 顺序，以及按文件类型的处理策略（例如构建配置宜手动合并、超大文件不宜整段 pick）。迁移过程中若出现编译错误，也可按错误类型协助判断是漏 commit 还是两分支接口签名不一致。

适用边界与注意点

• 功能模式无法保证 100% 覆盖，合并后的 commit 列表需人工确认；遗漏可通过迁移后编译错误反查。
• 强依赖判定依赖对 diff 与引用关系的分析，复杂反射、动态加载等场景需额外人工核对。
• HTML 报告默认写入项目 docs/；CR 行尾文件必须在报告中视为高风险并先规范化再合并。
• 适用于任意语言/框架，但构建与依赖检查会按检测到的项目类型选用对应清单（Gradle、npm、Go mod 等）。