仓库与分支
按仓库、默认分支和更新时间组织公开项目清单。
面向 git clone、源码归档、GitHub REST / GraphQL API 与增量同步,以不限流量和项目级带宽支撑长期代码数据任务。
仓库发现、归档下载、历史对象和大文件具有不同传输特征,应拆分队列和验收口径。
按仓库、默认分支和更新时间组织公开项目清单。
区分源码归档、提交历史和大文件对象的下载策略。
根据更新时间或对象标识同步变化,避免重复全量下载。
记录来源、许可证和公开访问依据,支持后续数据治理。
支持公开仓库、源码归档、提交历史和大文件对象的持续传输。
批量同步公开仓库、默认分支和源码归档。
获取提交、树和对象历史,保留时间与关联。
按更新时间发现变化,只同步新增或变更对象。
同步节点通过代理下载归档或 Git 对象,失败任务按仓库或对象重试。
记录来源、仓库标识、分支、更新时间和许可信息。
按是否需要历史、对象关系和大文件选择方式。
按来源限制并发,失败时重跑仓库或对象。
网络下载完成后再进入代码清洗和数据治理。
不限流量适合长期仓库同步,定制代理池可按代码托管来源分配连接与带宽。
监控仓库完成率、引用与对象完整性、重试量、有效吞吐和增量延迟。
项目带宽以聚合容量提供;目标响应、对象大小、并发、工作节点和存储会影响实际吞吐。
源码归档和 API 请求使用 HTTP 代理,git clone 可通过 Git 代理配置接入。
git \
-c http.proxy="http://user:pass@proxy.123proxy.cn:9000" \
clone \
--filter=blob:none \
"https://target.example/public/repository.git"
代理选择、工具接入、下载性能、失败重试与数据完整性。
先记录仓库大小和失败阶段,使用 --filter=blob:none、浅克隆或归档下载降低单任务体积,并在仓库粒度设置超时与重试。持续失败时应分别检查目标服务、Git 客户端与代理链路。
不是。页面面向依法可访问的公开代码托管、仓库归档和 HTTP 对象。具体目标应通过代表性仓库验证协议、限速和对象完整性。
本方案不提供绕过访问控制的能力。私有仓库必须由客户拥有合法授权并自行提供合规凭据。
长期同步仓库、归档、历史对象和大文件会产生持续传输,失败重试也会增加总量。不限流量更便于控制预算。
不能。代理可以为网络请求提供不同出口,但账号或 Token 的 API 配额仍由代码托管平台控制。开发者应读取响应头、控制并发并按平台规则处理限额。
只需要当前源码时归档通常更轻;需要提交历史、分支和对象关系时使用 Git。应按数据目标拆分任务。
不包含在标准代理方案内。许可证识别、敏感信息处理、代码解析、去重和质量过滤由客户数据管道负责。
它是单项目聚合容量,不代表单个仓库或连接可以达到该速度。吞吐来自多个来源和工作节点的整体并行。
应保存仓库更新时间、引用或对象标识,根据变化只调度新增任务,避免重复全量传输。
建议记录来源 URL、抓取时间、公开状态、许可证和处理规则,并遵守知识产权、隐私、目标服务条款与适用法律。