开发工具

这个类别解决什么问题

让你能安全地保存、回溯和协作修改代码，并且让发布流程可重复。

什么时候需要

从第一个提交开始。这是唯一一个几乎不可能推迟的类别。

选择时看哪些指标

这些是评估这类服务时通用的判断维度，不针对任何具体厂商。

• 私有仓库与协作人数限制
• CI/CD 的免费额度与排队时间
• 访问稳定性
• 与部署平台的集成程度
• 数据可导出性

中国开发者特别需要考虑什么

中国大陆的访问稳定性会直接影响日常开发体验与 CI 速度，建议提前评估并准备备用方案。

这一层的成本结构

开发工具这一层的成本分三块。一是席位或私有仓库的订阅费，按人头计，属于固定成本，团队越大越明显。二是 CI 分钟数，随提交频率与测试时长线性增长，是典型的可变成本，也最容易被忽略——一个跑十五分钟的测试套件，每天推送几次，一个月就能吃掉上万分钟。三是 AI 编程助手的席位费或调用费，重度使用者这一项可能超过托管费。单人起步多为零成本，规模上去后账单从人头转向用量。

常见误区

• 把仓库和 CI 绑在同一家平台上。哪天网络或账号出问题，代码看不了、流水线也停了。更合理的做法是把构建命令写成普通脚本，本地能跑同一套命令，换平台时只改触发方式。
• 把密钥提交进仓库。发现后删掉文件也没用，历史记录里还在。做法是首次提交前写好忽略规则，只提交环境变量示例文件，真实密钥放平台后台，推送前再扫一遍确认没有漏网。
• 只保留一份远程仓库，本地不留完整克隆。远程账号被封、误删或服务中断时就没有退路。至少让本地有一份完整历史，重要项目定期导出一次镜像存到别处。

从零开始的上手顺序

1. 装好 git，先设好用户名与提交邮箱。它会写进每一条提交记录，用长期不换的那个，以后迁移平台时提交归属不会乱。
2. 在托管平台先建一个空的私有仓库，再从本地初始化后推上去。顺序反过来容易在首次拉取时撞上 README 冲突。
3. 第一次提交之前写好忽略规则和环境变量示例文件，把密钥挡在门外，不要等出事后再回头清理历史。
4. 加一条最小流水线：只做安装依赖加一条 lint 或单元测试。先证明它能跑通，再逐步加步骤，避免一次写太长没人看得懂。

在不同业务模式中的作用

常见问题