The dependency graph can identify your project's dependencies using the following methods.
| Method | How it works |
|---|---|
| Static analysis | Parses manifest and lock files in your repository |
| 依赖项提交 API | Accepts dependency data you submit programmatically |
Once dependencies are in the graph, you can receive Dependabot alerts and Dependabot security updates for any known vulnerabilities.
Static analysis
When you enable the dependency graph, GitHub scans your repository for supported manifest files and parses each package's name and version. The graph updates when you change a supported manifest or lock file on your default branch.
Static analysis can identify:
- Direct dependencies explicitly defined in a manifest or lock file
- Indirect dependencies—dependencies of these direct dependencies, also called "transitive dependencies"—but only if they are defined in a manifest or lock file, not if they are resolved at build time
For the most reliable graph, you should use lock files (or their equivalent), because they define exactly which versions of the direct and indirect dependencies you currently use. Lock files also ensure that all contributors to the repository are using the same versions, which will make it easier for you to test and debug code.
The 依赖项提交 API
You can call the 依赖项提交 API in your own script or workflow. This is useful if:
- You need to submit transitive dependencies that cannot be detected from lock files.
- You need to create custom logic or are using an external CI/CD system.
Dependencies are submitted to the 依赖项提交 API in the form of a snapshot. This is a list of dependencies associated with a commit SHA and other metadata, reflecting the current state of your repository.
If you are calling the API in a GitHub Actions workflow, you can use a pre-made action for your ecosystem that automatically gathers the dependencies and submits them to the API. Otherwise, you can write your own action or call the API from an external system.
可以使用 REST API 提交项目的依赖项。 这使你可以将依赖项（如编译或生成软件时解析的依赖项）添加到 GitHub 的依赖项关系图功能，从而更全面地了解项目的所有依赖项。
依赖项关系图显示你使用 API 提交的任何依赖项，以及从存储库中的清单或锁定文件（例如 package-lock.json JavaScript 项目中的文件）标识的任何依赖项。 有关查看依赖项关系图的详细信息，请参阅 探索仓库的依赖项。
提交的依赖项将收到 Dependabot alerts 和 Dependabot security updates 以处理任何已知的漏洞。 你只会收到来自 GitHub Advisory Database 支持的生态系统之一的依赖关系的 Dependabot alerts。 有关这些生态系统的详细信息，请参阅 关于 GitHub 公告数据库。 对于通过 依赖项提交 API 提交的可传递依赖项，如果更新可用，Dependabot 将自动打开拉取请求以更新父依赖项。
提交的依赖项在组织的依赖项见解中_不_可用。
For more information, see 使用依赖项提交 API.
Prioritization
依赖项关系图可以通过三种不同的方式来了解依赖项：静态分析、自动提交和手动提交。 一个仓库可以配置多种方法，这会导致同一个包清单被扫描多次，而且每次扫描可能会产生不同的结果。 依赖项关系图使用去重逻辑来分析输出，为每个清单文件优先选取最准确的信息。
依赖项关系图会依据以下优先级规则，仅显示每个清单文件的一个实例。
- 用户提交具有最高优先级，因为它们通常是在项目构建期间创建的，包含最完整的信息。****
- 如果存在来自不同检测器的多个手动快照，这些快照将根据关联器按字母顺序进行排序，并且会采用第一个快照。
- 如果有两个使用相同检测器的关联器，已解析的依赖项将合并。 有关关联器和检测器的详细信息，请参阅 适用于依赖项提交的 REST API 终结点。
- 自动提交具有第二高的优先级，因为它们同样是在项目构建期间创建的，但并非由用户提交。****
- 静态分析结果会在没有其他可用数据的情况下被采用。****