企业官网建设流程全解析

做开源项目这几年，被问得最多的一个问题不是“某个框架怎么用”，而是“我的代码到底放哪”。GitHub 不用多说，全球开发者聚集地，腾讯云 CNB 则是国内这两年冒出来的代码托管新选择。很多朋友一上来就问“哪个免费额度多”，但实测下来我发现，单看数字意义不大，关键还得看你的开源项目想解决什么问题、在哪儿协作、自动化能做到什么程度。这篇文章我会把两个平台的免费额度掰开揉碎讲清楚，再附上我最近把一个项目从 GitHub 迁到 CNB 的完整操作记录，希望能帮正在纠结托管选型的人少走点弯路。

1. 托管选型的底层逻辑：免费额度不是唯一指标

1.1 代码托管到底在解决什么问题

先说个容易被忽略的事实：代码托管平台本质上是“代码的办公室”，不只是网盘。你租办公室，看的不是柜子多大，而是水电、网络、会议室、物业响应速度。换成代码托管，就是仓库容量、协作人数、构建机器、制品分发、权限管理这一整套东西。

GitHub 起家的逻辑是“社交化开源”，它最值钱的是那几亿开发者形成的网络效应——你的项目放上去，别人能搜到、能提 Issue、能提 PR、能点 Star，这是任何国内平台短期追不上的。而腾讯云 CNB 这类平台的思路更偏“研发效能工具”，它不只是给你放代码的位置，还想把代码托管、CI/CD、部署、制品库这些开发流程都串起来，尤其跟腾讯云的计算、存储、容器等产品深度绑定。目标用户也很明确：国内开发者和企业，希望代码在国内访问速度更快，自动化构建和上线链路更顺畅，并且结算方便。

理解了这层定位差异，再去看免费额度就清晰多了。GitHub 的免费策略是在“开源社区基础设施”这个框架下设计的，所以公共仓库很慷慨，私有仓库和 Actions 分钟数则明显收紧；CNB 的免费策略更像“新平台拉新”，仓库、团队、构建等基础能力尽量放开，先把你留在平台里，后续再通过企业版、更高并发、更长的制品保留期赚钱。

1.2 免费额度只是起点，背后还藏着这些成本项

很多新手对比免费额度时只盯着“能建多少个私有仓库”，这是典型的只看柜子、不看房租。我建议大家按下面五个维度去审视一个托管平台的免费额度。

• 协作人数：个人开发者无所谓，小团队最敏感。免费版到底能加几个协作者？超过之后是按人收费还是直接不能用？这是最容易踩坑的地方。
• 构建分钟数：开源项目如果重度依赖 CI，公共仓库免费 / 私有仓库限额之间的差别非常大。GitHub Actions 在免费套餐里对公共仓库是无限分钟数，对私有仓库有月度限额，超出就按分钟计费，这个坑我见过太多人踩。
• 容量与带宽：仓库本身一般够用，但 Git LFS（大文件存储）才是无底洞。GitHub 的免费 LFS 额度大约是 1GB 存储和 1GB 月流量，一旦项目里有安装包、模型文件、固件镜像，很快就用超。
• 附属功能：比如 Packages 制品库、镜像仓库、静态站点托管、企业级审计日志，免费额度里到底包不包含，包含多少，直接影响你后期要不要掏钱。
• 网络与合规：国内访问第三方的服务器和议价能力不在你手里，网络波动是客观存在的；CNB 这类国内平台在数据本地化和访问速度上天然有优势，但如果你要做全球性开源项目，曝光度和国际化协作又是短板。

把这些维度想清楚，再回来看“免费额度对比”才有意义。

2. GitHub 免费额度的真实盘点和常见认知误区

2.1 GitHub Free 到底免费哪些东西

先说结论：GitHub 对纯开源项目确实非常慷慨，这也是它这么多年依然是开源默认选择的核心原因。以个人账号的 Free 档为例，公开仓库没有数量限制，GitHub Actions 在公开仓库里也基本不额外收分钟数费用（实际按官方文档规则执行，通常公共仓库的储存和分钟数免费），所以一个正经的开源项目，只要不碰私有仓库高级功能，基本可以零成本跑起来。

私有仓库这块，GitHub 这几年也放开了很多。个人免费账号可以创建不限数量的私有仓库，还能配合移动端、Issues、Projects 这些基础功能使用。但注意几个边界：免费的私有仓库在权限模型、分支保护、Codeowners 这些高级协作能力上受到一定限制；组织账号（Organization）免费档的私有仓库虽然也能建，但功能裁剪得更明显，尤其是团队管理和安全审计相关的能力，基本是面向付费套餐设计的。

GitHub Pages 也是很多开源项目喜欢用的免费福利，个人和项目站点都能托管静态页面，公共仓库免费。但 Pages 的构建频率、自定义域名 HTTPS 支持等细节，免费档和付费档有差异，别等发布到一半才发现自定义域名受限。

2.2 免费额度里容易忽略的暗坑

第一，GitHub Actions 的账单最容易失控。很多团队把私有仓库也接到 Actions 上，结果月底一看账单傻眼。免费套餐对私有仓库的分钟数是有上限的（我记得大致是一个月两千分钟量级，具体以官方账单页为准），跑一次完整测试、构建镜像、部署环境，可能几分钟就过去了。而且 Actions 的计费按运行器类型区分，Windows/macOS 运行器的倍率远高于 Linux，同样的分钟数，跑 macOS 构建消耗速度快得多。

第二，Git LFS 是真正的“吞金兽”。我接手过一个小型硬件开源项目，里面放了不少 PCB 设计文件、3D 模型，仓库体积直接飙到 5GB 以上。GitHub 免费 LFS 额度根本不够，超出后的流量费和存储费都不便宜。开源项目如果涉及二进制资产，一定要尽早规划 LFS 策略，或者把大文件挪到对象存储。

第三，账号安全和双重验证虽然免费，但如果你用免费组织账号做商业项目，审计日志、SSO 单点登录这些合规功能基本都要付费。很多国内外包团队到后期都会因为上不了 SSO 被迫升级套餐，这属于“免费额度看不到的隐形成本”。

第四，还有一个常被吐槽的点：GitHub 在国内的可达性整体可以，但偶尔会遇到访问不通或页面加载很慢的情况。这个问题我不展开说解决方案，但你要有心理准备——如果你的团队成员主要在境内，GitHub 的体验很可能成为日常开发里的阻力，这也是很多人转向 CNB 等国内平台最现实的原因。

3. 腾讯云 CNB 免费额度与产品定位

3.1 CNB 是什么，适合谁来用

腾讯云 CNB 是腾讯云推出的代码托管与研发协同平台，产品形态和 GitHub 类似，都是基于 Git 的代码托管，但它的侧重点从第一版开始就很明显：让开发者把“代码托管 + CI/CD + 部署”整套流程在腾讯云生态内闭环。你可以把它理解成“长在腾讯云里的研发工作台”，当你需要把代码一键构建并部署到腾讯云服务器、容器服务或函数计算时，CNB 和云资源的衔接比其他平台顺滑很多。

适合 CNB 的主要是三类人：一是团队服务器和域名都在国内、受够了跨地域协作延迟的开发者；二是项目对数据合规和数据本地化有明确要求，希望代码不落境外服务器的团队；三是需要快速完成 CI/CD 链路、不太想自己在服务器上折腾 Jenkins 的团队。如果你是做国际影响力开源项目，那 GitHub 依然是不可替代的主阵地，CNB 更适合作为国内同步通道。

3.2 CNB 免费额度的核心边界

关于 CNB 的免费额度，我特别强调一句：老平台的功能和配额比较稳定，新平台则经常调整，所以任何第二手信息都可能过时，最准的还是看官方产品页面和文档，下面说的只是我体验时的版本。

我印象比较深的有几点。CNB 为新用户提供的免费套餐里，私有仓库基本不限制数量，这比早期很多国内平台“免费只能用公共仓库”的策略要大方得多。对个人和小团队来说，只要不追求高级企业功能，日常开发所需的仓库、成员协作、基础 CI 流水线，免费档能覆盖大部分场景。

构建这块，CNB 内置了 CI/CD 能力，免费额度一般会按月给一定时长的构建分钟数，具体数值需要看当前活动页面。由于 CNB 的服务节点都在国内，构建拉取依赖、推送制品到腾讯云的速度明显比海外平台快，这算是免费额度之外的隐形收益。毕竟构建分钟数再便宜，如果频繁超时重试，实际消耗也是翻倍的。

另一个值得提的是 CNB 与腾讯云产品的打通——代码推上去之后，可以直接关联云函数、容器实例、静态网站托管等服务做自动部署。对于个人项目和小团队来说，这个“从代码到上线”的免费闭环价值很大，相当于省掉了单独购买 CI 服务和配置部署脚本的成本。

3.3 与 GitHub 的免费额度直观对照

下面这张表是我根据自己的使用体验整理的，比较粗糙，但足够帮你在两个平台之间做个初步判断。再次提醒：CNB 的最新配额请以官方页面为准，GitHub 的配额也请以官方文档为准，这里主要是给你一个选型框架。

4. 场景化选型：开源项目和个人项目到底怎么选

4.1 哪些情况无脑选 GitHub

如果你的目标是做一个被全世界开发者看到的开源项目，GitHub 基本是唯一选择。它的社交网络效应、搜索引擎权重、第三方工具生态（代码质量、安全扫描、文档生成、徽章系统）都不是短期内能被替代的。项目放在 GitHub，别人发现你的概率、提 PR 的意愿、用你项目时的信任感都更高。

举个例子，我去年把一个工具库放到 GitHub 上，没做任何推广，靠 README 里的关键词和 GitHub 的 Trending 算法，两周时间获得了三百多 Star，还收到了海外开发者的功能建议。这种“被看见”的能力，恰恰是国内平台免费额度给不了的。

另外，如果你的项目重度依赖 GitHub 生态里的某个功能，比如 Dependabot 自动依赖更新、CodeQL 安全扫描、GitHub Sponsors 捐赠，那么拿 GitHub 当主仓也是最省事的路径，因为这些功能迁到别的平台往往要自己找平替。

4.2 哪些情况 CNB 用起来更舒服

反过来，如果项目是公司内部用的工具库、课程配套的练手项目、或者主要给国内客户交付的解决方案，CNB 这类国内平台的优势就体现出来了。第一是速度，我实测拉取 CNB 仓库和推代码的体验，比连海外服务器顺滑得不是一星半点，尤其是团队同时做多人在线协作时，网络延迟对效率的影响会被放大。第二是云资源打通，代码构建完直接推到腾讯云容器服务或函数计算，整个 DevOps 链路不需要在两套体系之间来回切换。

CNB 的免费额度对“小团队私有协作”也特别友好。之前我在 GitHub 上建了一个私有仓库做商业项目，协作者多了之后有些高级功能受限，后来把项目同步到 CNB 作为国内协作主仓，成员管理、分支权限、合并请求的体验都很直接，没太感受到免费档和付费档之间那种“故意卡你一下”的割裂感。

4.3 两个平台并行的双托管策略

很多开发者会陷入“二选一”的纠结，但实际情况是，双托管完全可行，而且我用下来觉得性价比很高。核心思路是：GitHub 作为“门面”，承担开源展示、Issue 收集、PR 协作的职责；CNB 作为“生产”，承担国内自动化构建、云资源部署、内部协作的职责。

具体操作也不复杂。我通常是 GitHub 主仓库作为唯一真源（source of truth），任何提交先推 GitHub，然后通过平台自带的同步功能或 Git 的 push 命令，把代码增量同步到 CNB 的对应仓库。CNB 这边配置好流水线，代码一到就自动触发构建和部署。这样既保住了 GitHub 的开源生态优势，又享受了 CNB 的国内速度和云资源整合，两边的免费额度还都能用到。

当然双托管也有代价，最明显的是要维护两边的分支权限设置和自动化流程，刚开始会有点繁琐。但说白了，代码迁移的成本是一次性的，自动化同步和维护的成本是持续的，只要项目不是三天两头改目录结构，这套模式完全可以稳定跑下去。

5. 从 GitHub 迁移到 CNB 的完整实操记录

5.1 迁移前一定要做的三件事

我最近把一个中等规模的项目从 GitHub 迁到 CNB，整个流程跑下来大概一上午。正式动手之前，请先做三件事：第一，梳理仓库里有没有大文件，超过 100MB 的二进制文件极大概率会影响迁移速度，甚至触发平台限制，建议先把大文件从历史里清理掉，或者改用 LFS/对象存储。第二，整理现有的分支和标签，确认哪些是长期分支、哪些已经合并完可以删除，别把一堆僵尸分支也搬过去。第三，收集所有需要在新平台上下发到项目里的密钥，比如 CI 里用到的 Token、云服务的 AccessKey，迁移后这些都要重新配置，提前准备好能省很多时间。

5.2 仓库导入的几种方式

CNB 提供了比较友好的导入功能，支持直接从 GitHub 的 URL 拉取仓库。我自己的操作路径是：在 CNB 里新建项目，选择“从外部仓库导入”，粘贴 GitHub 仓库地址，然后授权或使用账号绑定，平台会自动把包括历史提交、分支、标签在内的完整 Git 数据拉过来。整个过程基本不需要在本地跑 Git 命令，对不熟悉命令行的人很友好。

如果你的仓库里有比较特殊的 submodule 嵌套子模块，或者使用了 LFS，导入之后一定要做验证——git submodule update --init --recursive这类操作在新平台上的行为可能和原平台不同，依赖的路径也要重新检查。我是建议导入完成后，本地 clone 一份新仓库，跑一遍构建脚本，确认代码能正常编译再继续。

5.3 迁移后的持续集成与自动化配置

代码过去了只是第一步，真正让项目“活”起来的是 CI/CD。CNB 的流水线配置方式和 GitHub Actions 有些不同，它更像一套可视化的编排界面，你可以把执行步骤拖拽串联起来，也可以直接编辑 YAML 文件。我迁移时先配置了一个最简单的流水线：代码推送触发 → 拉取代码 → 安装依赖 → 执行构建和测试 → 产出制品。跑通之后，再逐步加上部署到腾讯云服务器或容器服务的高级步骤。

有个细节容易被忽略：流水线里的环境变量和密钥一定要重新设置。GitHub Actions 的 Secrets 不会跟着仓库一起迁移，CNB 里的凭据也要重新录入。我当时漏配了一个私有 npm 源的 Token，导致第一次构建直接失败，排查了半天才反应过来。

另外，原来 GitHub 上的 Webhook 也要一并处理。如果你之前用 GitHub Webhook 触发了外部系统的消息通知、机器人报警之类，迁移到 CNB 后需要在新平台重新配置，或者改成从 CI 任务里直接调接口，否则消息通知会断掉。

5.4 迁移过程中容易踩的坑

整个迁移里最麻烦的不是代码本身，而是历史遗留问题。我列出三个亲测的坑：

• 大文件历史导致仓库臃肿：Git 会把所有历史版本都存在本地，哪怕后来删掉了大文件，早期提交里仍然有。迁移后的仓库如果体积暴涨，可以考虑用 git filter-repo 或相关工具重写历史，但注意重写历史后旧标签、旧 SHA 都会变，牵一发动全身，务必在分支上先测试。
• LFS 文件没有正确关联：导入后如果发现 LFS 文件变成了指针文件，说明 LFS 的下载地址或凭据没有正确配置，重新安装并配置 Git LFS 后，再拉取一次大文件。
• 权限和审查规则要重建：GitHub 上的 CODEOWNERS 文件能直接复制过来，但仓库的分支保护规则、必选审查人数、自动合并策略这些“平台副作用”不会自动迁移，一定要在 CNB 里重新配一遍。我迁移时忘记配置“主分支禁止直接推送”，团队小伙伴直接往 main 上推了两次代码，虽然没出大乱子，但确实打断了几次流水线。

6. 常见问题与选型速查

6.1 免费额度相关问题速查表

结合我平时在群里看到的提问，我把最常被问的问题整理成一张速查表，方便你收藏。

6.2 我的选型建议与经验心得

如果非要用一句话总结我的建议，那就是：开源项目想被人看到，主仓放 GitHub；想让代码在国内自动跑起来，CNB 是很好的配套选择。判断标准不要只看“免费多少 GB”，而是看你的项目生命周期里，最消耗成本的是仓库容量、构建分钟、协作人数，还是平台生态。

另外多说一句关于“免费额度”的心态。免费额度是平台用来降低你决策门槛的手段，不是长期承诺。我曾见过有人把商业项目的全套 CI 压在一个平台免费额度上，结果平台一改规则，整个发布流程就被迫中断。所以，哪怕你现在用的是免费档，也一定要把流水线配置、密钥管理、构建脚本做成一键可迁移的状态，这才是不被任何平台绑定的核心能力。

最后分享一个小技巧：如果你决定双托管，可以在 GitHub 侧放一个定时工作流，每天夜里把代码自动同步到 CNB，两边始终保持一致。这样就算主平台偶尔不可用，你随时切到备用仓库继续干活，风险基本为零。这个方案我用了几个月，省心且可靠。