先看协作形态
公开开源库需要可发现性、Fork、讨论区和贡献流程。私有产品团队通常更在意权限、分支规则、评审效率和可审计性。
代码托管是源码、评审、发布、CI/CD、软件包和团队权限的控制平面。好的免费方案应该先匹配协作模型,而不是只看仓库数量是否不限。
| 提供商 | 免费存储 | 月流量 | 规格 / 算力 | 连接限制 | 关键限制 | 操作 |
|---|---|---|---|---|---|---|
GitHub全球开源默认平台 | 仓库数量不限 | GitHub Free:Packages 含 500MB 存储 / 1GB 传输,按月重置 | 提供源码托管、Pull Request、Actions、Packages 和完善的协作生态 | 公开/私有仓库数量不限,支持组织级协作 | Git LFS 与私有包的传输/存储单独计费;无支付方式时额度耗尽会直接阻断使用 | 访问官网 ↗ |
GitLabDevSecOps 全家桶 | 10 GiB 存储 | 每月 400 计算分钟 | 免费层包含代码管理与 CI/CD,并含 5 个授权用户和 GitLab.com 项目存储 | 免费层 5 个授权用户 | 免费方案上限为 5 个授权用户和 400 计算分钟,额外资源需单独购买 | 访问官网 ↗ |
Bitbucket CloudAtlassian 代码工作区 | 工作区 1 GB 存储 | 每月 50 构建分钟 | 支持不限私有仓库、部署环境、代码洞察和适合小团队的 CI/CD 钩子 | 免费方案最多 5 个用户 | 永久免费仅限 5 个用户;额外构建分钟和 Git LFS 带宽需单独付费 | 访问官网 ↗ |
Gitee中国区 Git 托管 | 支持公开和私有仓库 | 提供代码托管、评审、Issue 跟踪和 CI/CD 集成 | 面向中国团队的 Git 托管平台,支持协作与 DevOps 工作流 | 支持团队和企业级协作以及项目组织管理 | 属于中国本地托管方案,具体配额和能力依赖当前产品计划 | 访问官网 ↗ |
Azure DevOps Services云端 Repos + Pipelines | 私有仓库不限量 | 在同一个云 DevOps 工作区中整合 Azure Boards、Pipelines、Test Plans 和 Artifacts | 提供云端私有 Git 仓库、Pull Request、分支策略和原生 CI/CD 集成 | 可通过 Azure 账号和服务授权灵活扩展团队规模 | 托管在 dev.azure.com,更适合视为一体化 DevOps 工作区而不是纯 Git 托管 | 访问官网 ↗ |
阿里云 Codeup中国区 Git 托管 | 企业级 Git 仓库 | 阿里云 DevOps 工作区,整合仓库、代码评审和 CI/CD | 面向中国团队的阿里云代码托管服务,提供仓库管理和协作流程 | 云原生项目与组织协作模型 | 属于中国区产品入口,价格和额度更适合以本地控制台或官方页面为准 | 访问官网 ↗ |
Gitea自托管 Git 服务 | 用户和仓库不限量 | 取决于自有服务器容量 | 轻量级自托管 Git 服务,含代码托管、Issue、Pull Request、项目管理、Packages 和 Actions | 小团队场景下 2 核 CPU + 1GB 内存即可运行 | 基础设施和运维都需要自己负责;它不是免费 SaaS 配额,而是自管理部署选择 | 访问官网 ↗ |
Codeberg非营利社区托管 | 仓库数量不限 | 部署在欧洲,并提供 Pages、Translate 和 Woodpecker CI 服务 | 由社区驱动的 Forgejo 托管平台,适合自由软件项目,并提供 Pages 与协作工具 | 由社区推动、依赖捐赠支持的基础设施 | 更强调自由软件价值而非商业免费;服务持续性依赖社区支持和捐赠 | 访问官网 ↗ |
当你更看重生态覆盖、公开协作、Issue 模板、Pull Request、Actions 和第三方集成,而不是最大免费存储时,GitHub 通常是默认选择。
当代码托管、CI/CD、镜像仓库、安全扫描和项目管理都希望放在同一个产品界面里时,GitLab 更合适。
团队已经使用 Jira 和 Confluence,并且主要需求是小团队私有仓库时,可以优先看 Bitbucket。
当数据位置、内网部署、低资源占用和运维掌控感比 SaaS 便利性更重要时,可以选择 Gitea。
公开开源库需要可发现性、Fork、讨论区和贡献流程。私有产品团队通常更在意权限、分支规则、评审效率和可审计性。
源码本身通常不大,但 Git LFS、Release 附件、构建产物、Packages 和容器镜像往往会快速撞到单独配额。
代码托管很少是孤立系统。迁移代码前,应确认流水线分钟数、密钥管理、部署集成、缓存行为和 Runner 选择。
小团队可以先用邀请协作,但正式团队要清楚 SSO、组织所有权、双因素认证、权限审查和员工离职交接怎么处理。
很多平台仓库数量不限,但免费方案会限制用户数、授权席位、组织能力、分支保护或高级评审控制。
大二进制文件会让仓库克隆长期变慢。应使用 Git LFS、包仓库、对象存储或 Release 附件,并设置清晰保留规则。
密钥扫描和分支规则有帮助,但团队仍需要环境隔离、最小权限 Token、轮换机制和评审纪律。
Git 历史容易迁移,但 Issue、Pull Request 讨论、Wiki、Packages 和 CI 日志未必能干净迁走。
公开可见性、贡献者引导、Issue 模板、Release 和文档页面优先时,可以用 GitHub 或 Codeberg。
私有 SaaS 产品可以用 GitHub、GitLab、Bitbucket 或 Azure DevOps,并配置强制评审、保护分支、CI 检查和部署环境。
当国内访问速度、本地合规和中文运维支持很重要时,可以看 Gitee 或阿里云 Codeup。
开源项目通常默认选 GitHub,因为它有可发现性、Fork、Actions、Issue、Release 和贡献者生态。如果更重视社区所有的基础设施和自由软件价值,可以看 Codeberg。
应比较席位数、分支保护、强制评审、CI/CD 分钟数、包存储、Git LFS、审计日志、SSO、组织所有权,以及成员离开时移除权限是否容易。
软件本身免费且轻量,但托管并不是零成本。你仍然要承担服务器、备份、升级、监控、安全补丁和运维时间。
通常不应该。Git 历史最好只保留源码。大文件应根据使用方式放到 Git LFS、Release 附件、包仓库、镜像仓库或对象存储里。
Git 仓库本身很容易迁移,但 Issue、Pull Request 评审、讨论、Wiki、Packages、CI 日志、分支规则和权限通常需要单独规划迁移。