企业官网建设流程全解析

免费工具够不够用，这事真得看你怎么定义“够用”。我见过不少团队一上来就买企业版，一个月烧掉几千块，结果日常只用到仓库和Issue。也有团队印象还停留在七八年前，一口咬定GitHub私有仓库要收费，非要内网搭一套重型系统，白白折腾两星期。2026年这个时间点，各家基础免费版的边界其实已经和大多数人的记忆彻底不一样了。这次我拉了一个5人小组，用同一个真实项目当“小白鼠”，把7款主流团队编程管理工具的基础免费版全部跑了一遍，从注册建仓、分支保护、代码审查、Issue流转，到CI/CD额度和国内访问体验，挨个记录踩坑和惊喜。这篇文章不吹不黑，只讲实测数据和选型结论。

需要先说清楚的是，我测的全都是“基础免费版”，也就是不花一分钱能长期用的方案，不是试用期30天的那种“伪免费”。适合准备拉团队但预算有限、想先跑通流程再决定是否付费的开发者。

1. 免费梯队的真实水位：有些“免费”是坑，有些是金矿

1.1 选品逻辑：7款工具是怎么选出来的

2026年的团队编程管理工具市场，远不止“GitHub还是GitLab”这道二选一。为了覆盖不同场景，我按三种形态做筛选：国际SaaS、国内SaaS、自托管开源方案。入选必须同时满足三个条件，缺一个都直接淘汰：

• 在2026年上半年仍然提供明确的基础免费档位，且不是一次性试用；
• 能支持至少3人以上协作，不是个人单机版；
• 在国内开发者中有一定用户基础，至少能搜到中文资料和社区问答。

最终入选的7款是：

为什么不测极狐GitLab？因为它的免费版逻辑和GitLab SaaS基本同源，而极狐在合规和下载速度上的优势，我在文中讲GitLab时顺带对比就够了。多一款重复试验，不如把省下的精力放在差异项上。

1.2 评测环境与统一打分明细

为了不让测试变成“注册完截个图就走”的云评测，我们实际把一个宠物社区App的后端重构项目搬进了7个平台：5人组（前端2人、后端2人、测试1人），持续两周，约220次代码提交，创建了60多个Issue，走了30多次合并请求，每个平台配置了至少一条流水线。项目仓库不算大，代码加历史共约280MB，Git LFS对象约1.2GB，这个体量能很好地反映中小企业典型使用场景。

打分维度没有拍脑袋，而是按团队真实使用频率和踩坑成本加权：

每个维度按1到10分打分，最后加权得总分。后文所有结论都基于这张表和实际截图记录。

2. 第一眼印象：注册、建仓、拉代码的速度实战

2.1 国际三强的开箱体验

GitHub Free现在的注册流程相当顺滑，邮箱+密码就能起步，手机验证也支持国内号码。免费版已经放开了无限私有仓库，3人以上的组织仓库同样免费，这点和很多人的旧记忆完全不同。但“开箱”不等于“跑得快”，在华东办公网络直接访问GitHub，页面加载和clone速度会受跨境网络波动影响，上午和晚上的表现差异明显。我们测了20轮git clone，平均速度大概在1.2MB/s到3.8MB/s之间徘徊，大仓库首次拉取需要耐心。

GitLab Free的开箱体验明显更“重”。注册时就要选择使用场景，界面信息密度高，免费版里同时塞了代码托管、CI/CD、容器镜像库、Wiki、里程碑一堆入口。对老手来说这是优点，新手容易懵。值得表扬的是GitLab在国内没有专门节点，但它的网页端静态资源加载策略比GitHub稍好，白屏时间短一些。

Bitbucket Free给我最大的感受是“被Jira绑架”。注册必须走Atlassian账号，填了一堆问卷，团队规模、项目类型、岗位角色，一套流程下来比另外两家多花了差不多五分钟。免费版限制工作区最多5个用户，刚好卡在我们团队人数上。它的界面干净，代码审查界面三栏对比（原始、当前、差异）做得很好，但受限于国内网络，速度同样不算快。

2.2 国内平台的自来熟

Gitee基础版的中文环境不用多说，手机号验证后直接能用，clone速度本地化优势明显，同一网络下实测能跑满办公宽带（我们这边大约12MB/s）。但免费版的私有仓库数量限制很死，一个账号只有5个私有项目额度，这对“一个项目一个仓库”的正规团队来说是个硬约束。Gitee的价值更多体现在开源项目托管，或者团队愿意把仓库设为公开的场景。

CODING基础版走的是腾讯云账号体系，注册时会被引导开通腾讯云服务，不过不产生费用。初始界面提供了一堆项目模板（Scrum、Kanban、空白项目），这在7款工具里是独一份。代码托管、项目协同、持续集成、制品库都是从同一个控制台进入，对“不想在多个平台间跳来跳去”的团队极友好。基础版的成员人数限制是5人，超出后只能看不能写，这点和Bitbucket类似。

2.3 自托管型工具的部署门槛

Gitea是我个人比较偏爱的一款。单二进制文件，或者直接用Docker跑，资源占用低到发指，2核2G的小云主机带起来毫无压力。部署命令极简：

docker run -d \ --name=gitea \ -p 3000:3000 -p 2222:22 \ -v /var/lib/gitea:/data \ gitea/gitea:latest

10分钟不到就能得到一个完整的Git托管平台。但如果团队成员不是所有人都会碰服务器，反向代理、HTTPS证书、SSH端口这几个环节会拦下一批人。我们小组里测试同学搞不定Nginx配置，最后是后端同事帮忙收尾的。

禅道开源版的部署门槛同样不高，官方提供了Linux一键安装包，PHP+MySQL环境，下载解压执行脚本就能跑起来。它和Gitea定位完全不同：禅道不提供真正的Git托管，它的核心是项目过程管理，代码仓库要靠Webhook挂接外部Git服务，这一点在选型前一定要想清楚。我们实测时是“禅道管需求、Gitea管代码”的组合，勉强弥补了闭环缺口，但也增加了系统维护成本。

2.4 首次推送的延迟体验

统一测试文件（约50MB）推到各平台，记录耗时：

这里的绝对速度不代表永久表现，跨境网络本质上是波动的，但国内平台和自托管在时延上的优势是结构性的。

3. 代码托管与分支保护：免费版的上限到底在哪

3.1 私有仓库与成员管理

“能不能建私有仓库”在2026年已经不是免费版的生死线，真正的分水岭在“私有仓库数量”和“成员人数上限”。

GitHub和GitLab在人数上最慷慨，适合未来可能扩张的团队。Bitbucket和CODING的5人限制是硬伤，第6个人加入时要么踢人要么付费。Gitee的私有仓库数量是5个，对“一个项目拆多个仓库”的微服务团队极其不友好。Gitea只要你服务器扛得住，想建几百个仓库都行。

3.2 分支保护与强制审查

分支保护是团队协作的刚需，没有它，一个误操作就能把代码推到主干。7款工具在这一项的差距非常明显。

GitHub Free支持受保护分支，可以设置不允许直接push、要求PR通过、要求状态检查通过。但在私有仓库中，部分高级选项，例如“必须由代码所有者审查”和“必须满足一定数量的审查人”，需要付费方案。我们实测免费版可以做到“禁止直接push + 要求1个审查人”，这个下限已经能满足大部分小团队。

GitLab Free的分支保护能力比GitHub更慷慨，允许配置多个受保护分支，可以指定“谁可以合并”“谁可以推送”，免费版就支持Code Owners规则（早期版本需要付费，2026年的免费版已经放宽了基础用法），这点让我有些意外。

Bitbucket Free的分支保护集中在“Branch restrictions”，可以设置禁止直接push到主干，但免费版的合并检查选项不如GitLab多，要求特定审查人数这种细粒度控制被划到了付费侧。

Gitee免费版可以开启“保护分支”，也支持PR评审。但它对分支的规则继承做得一般，多个分支需要逐个配置，项目一多容易漏。

CODING的“分支保护”做成了可视化的规则配置，可以针对分支名通配符设置，还支持“评审必过”策略。实测下来是国产工具里分支策略最接近GitLab的一家。

Gitea支持受保护分支，可以设置推送权限、合并权限、要求PR。但由于它走的是轻量路线，规则本身不如GitLab丰富，特别是自动化状态检查这条，需要配合Gitea Actions才能玩转。

禅道开源版压根没有分支保护概念，因为它不托管Git。如果团队需要强分支管理，禅道只能当辅助工具。

3.3 实测一次完整的Review流程

我们用同一个任务“用户登录接口加验证码”，在每款工具上走了一遍标准流程：创建分支、写代码、提交、发起MR/PR、指定审查人、审查通过、合并。

• GitHub和GitLab的PR/MR流程最规范，页面自动展示文件变更数、评论线程、合并冲突状态，审查人可以直接在差异视图里逐行留言，体验是天花板级别。
• Bitbucket的Pr界面三栏对比好用，但合并按钮的位置和交互不够直觉，团队里两位前端同学都遇到过“找不到Merge按钮”的情况。
• Gitee的PR体验接近GitHub，但细节上差一点，比如没有自动检测目标分支是否最新，合并后偶尔需要手动同步。
• CODING的MR体验比预期好，特别是“检查清单”功能，能把“单元测试通过”“接口文档已更新”这类人工检查项固化在合并流程里，执行力比纯靠自觉强很多。
• Gitea的PR不支持拖拽排序评论，但基础Review流程完整，轻量团队够用。
• 禅道在这一环节直接退出比赛，它把需求状态改一改、关联代码提交记录，但无法承载真正的代码审查。

实测后我们统一得出一个结论：如果团队有“强制代码审查”的诉求，GitLab Free、CODING、GitHub Free是首选；没有强规则诉求，想轻量跑起来，Gitea完全够用。

4. Issue、看板与迭代：把需求变成可控的任务流

4.1 Issue模型与字段灵活性

代码托管是编程管理的骨架，Issue模型是血液。不同工具的Issue设计思路差距很大。

GitHub的Issue非常克制的简约：标题、描述、标签、Assignee、里程碑、项目面板。它刻意不给太多自定义字段，因为GitHub相信“链接和讨论”比“填表”更重要。Issue里可以直接引用PR、提交号和另一条Issue，自动形成关系图谱。适合习惯了“少即是多”的工程师文化团队。

GitLab的Issue模型更重，支持权重、到期日、任务列表、父子Issue，还有“Related issues”和“Blocking issues”两种关联类型。这对做迭代计划很有利，但配置项一多，团队里总有成员会忘记填。

Bitbucket的Issue功能其实有点鸡肋，简洁得很，更像是给仓库附带的“留言板”，真正好用的项目管理在Jira那边。如果买了Bitbucket但不买Jira，项目管理体验约等于裸奔。

Gitee的Issue提供类型（缺陷/任务/需求/建议），有优先级和关联仓库功能，可用性不错。但由于免费版私有仓库只有5个，Issue跨仓库串联能力被阉割得很尴尬。

CODING在Issue这块做得比Gitee更深入：需求、任务、缺陷是拆分的一等公民，每个字段都可以自定义，还有“用户故事地图”这种在国产工具里不多见的视角。实测下来它的项目管理模块已经逼近Jira的六成功力，对习惯中文操作界面的团队非常友好。

Gitea的Issue中规中矩：标签、里程碑、Assignee、引用联动都有，字段自定义较弱。但这本就不是它的定位，轻量嘛。

禅道的Issue本质上不是Issue，而是“需求、任务、缺陷、用例”四类对象，字段多、状态机完整、统计报表强大。缺点是灵活性和上手成本成反比，许多设置项不搞清楚，用起来会觉得很笨重。团队里如果有一位“流程控”管理者，禅道会让他狂喜；如果团队崇尚敏捷自由，禅道反而会成为负担。

4.2 看板与迭代管理

• GitHub用Projects（基础版）做看板，卡片支持拖拽，但自动化规则很有限，列状态变化时需要手动维护，重度使用会觉得心累。
• GitLab的Board和里程碑联动好，自由版就能配置多个Board，还支持按标签、Assignee过滤卡片，迭代管理体验在免费工具中数一数二。
• Bitbucket没有看板，想看板？去Jira。这是套娃式销售的老套路。
• Gitee的看板同样存在，但交互普通，卡片筛选能力一般。
• CODING的看板是它最出彩的部分，支持Scrum迭代、看板泳道、燃尽图，办一个正式的Sprint流程毫无压力。我们实测用它跑了两周迭代，5个人都表示比GitHub Projects顺手。
• Gitea的Projects看板极简，能拖卡片、能加标签，再复杂的需求就别指望了。
• 禅道的迭代管理是所有工具里最“重”的，创建迭代、关联需求、拆分任务、指派、记录工时、生成燃尽图，每一步都有规范，但也因此最适合被审计比较严格的公司。

这一轮CODING和禅道表现最强，GitLab紧随其后。如果你的团队想建立正经的迭代节奏，而不是“用聊天软件口头对齐”，CODING或禅道是更有支撑力的选择。

4.3 通知与协同细节

• GitHub的通知全靠邮件，Web端虽然有更新提示，但关掉浏览器就等于失联。实测中有两次PR被漏审，都是因为有人没及时看邮件。
• GitLab可以配置Slack等外部通知，但在国内企业常用的企业微信、钉钉上，免费版的官方集成支持一般。
• Bitbucket同样偏重邮件，有第三方集成但需要自己搭桥。
• Gitee支持Webhook，可以自己写脚本转发到群机器人，但官方没有点开即用的企业微信通知。
• CODING在通知这块是国产红利：官方提供企业微信、钉钉、飞书机器人插件，实测加入企业微信群后，MR评审、构建失败、缺陷指派都能实时推送，团队成员幸福感直线上升。
• Gitea支持Webhook，可以接钉钉群机器人，配置也很简单。
• 禅道自带通知设置，支持邮件和Webhook，也可以买官方扩展对接钉钉。

这个细节最容易在选型时被忽略，但它直接决定需求流转效率。工具再强，通知不到位，照样有人“错过”。

5. CI/CD与第三方生态：免费版够不够自动化

5.1 内置CI/CD的免费额度实测

自动化是团队效率放大器。一个残酷的现实是：不是每款免费版都给你完整的CI/CD能力。

如果你对CI/CD有硬需求，GitHub Free的2000分钟其实是最大的蛋糕。GitLab的400分钟看着数字小，但如果你在仓库里配置了复杂流水线（并行job多、artifact打包大），消耗会非常快。我们实测到第三周就触顶了，团队建CD流程时只能改到自托管Runner上。Bitbucket的50分钟在2026年依然抠门，只适合轻量演示，不适合真实开发。

5.2 最小可用流水线配置示例

GitHub Free配一套最简单的CI，大概长这样：

name: CI on: pull_request: branches: [main] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 20 - run: npm ci - run: npm test

这套配置YAML基本通用，抄下来改改就能跑。GitLab的CI写成.gitlab-ci.yml，核心段如下：

stages: - test - build test: stage: test image: node:20 script: - npm ci - npm test

CODING用的是Jenkinsfile风格，也可以用图形化编辑器配置，门槛最低。Gitee Go的配置需要进入它自己的流水线控制台，整体交互偏古早。Gitea需要先注册并启动Act Runner，然后在仓库里放gitea/workflows下的YAML文件，本质上和GitHub Actions同源，熟悉的人上手极快，但部署Runner这一步会挡住新手。

5.3 API、Webhook与第三方应用

• GitHub的应用市场（Marketplace）依然是免费的生态天花板，从Dependabot到各类Code Quality bot，基础版就能安装大量免费App。API没有额外限制，适合做自动化工具链。
• GitLab的集成数量略逊，但内置了容器镜像库和Terraform管理，对基础设施组很友好。
• Bitbucket的优势在Atlassian自家全家桶（Jira、Confluence、Opsgenie），但它对GitHub生态App的兼容性几乎为零。
• Gitee和CODING都有Webhook和OpenAPI，CODING还有Restful API权限分级，写个脚本拉取项目报告很方便。
• Gitea的Webhook支持通用格式，也能装在轻量服务上。禅道的REST API和二次开发能力在国产工具里很强，但需要PHP开发经验，不是所有团队都具备。

6. 稳定性、备份与“免费午餐”的隐藏条款

6.1 两周实测的服务可用性记录

我们连续两周每个工作日固定时间去各平台做一次“仓库列表加载+创建Issue”的冒烟测试：

• GitHub、GitLab的网页服务基本稳定，未遇到长时间故障，但GitHub有一次在晚间高峰期出现了较长的资源加载超时，重试后恢复。
• Bitbucket有两天下午出现接口响应变慢，单次请求超过6秒，最终依然成功。
• Gitee、CODING两周内都很稳，没有明显波动。
• Gitea的稳定性取决于自己的服务器，我们那台2C4G的小机器全程没出问题，但有一次磁盘空间只剩18%，push失败过一次，这算自建工具的特色风险。
• 禅道作为本地服务同样稳定，最大风险是部署机器的性能和维护。

稳定性评分，Gitee和CODING并列第一，国际三强紧随其后，自托管工具则取决于“你自己的运维水平”。

6.2 免费版的合规与安全边界

这轮测试最容易踩的隐性坑其实是条款问题。Gitee免费版允许私有仓库，但在开源项目建设上，它的一些推广机制会引导你开源；自建Gitea完全没有这类商业限制，代码和Issue数据100%在你自己的服务器上，安全可控，但反过来等于把备份和容灾的责任全揽到自己头上。

GitHub Free的私有仓库商用没有限制，但如果你用了它家的Copilot或Actions，要注意用量明细。GitLab Free和Bitbucket Free商用同样没问题。禅道开源版对商业使用很宽松，但官方会把“企业增强功能”如工时审计、安全报表留到付费版里。

关于数据备份，我的建议是：无论选哪个平台，每个周末跑一次全量镜像。以GitHub为例，一行命令就能备份：

git clone --mirror https://github.com/org/repo.git repo-backup.git

Gitea和禅道则可以直接导数据库和仓库目录的定时任务。免费平台不欠你数据，你自己的数据自己要负责，这是不会变的铁律。

6.3 人员与存储超限后的“温柔一刀”

免费版的超限不是直接封号，而是从“能用”变成“很难用”：

• Bitbucket和CODING在成员超过5人后，新成员无法写代码，现有成员不受影响，但项目基本停滞。
• Gitee的私有仓库超过5个时，新仓库只能建为公开，稍不注意就泄露商业代码。
• GitHub Actions分钟数耗尽后，CI任务排队但永不启动，构建一直显示“pending”，团队第一反应通常是“是不是网络问题”，排查半天才发现是额度耗尽。
• GitLab的共享Runner额度耗尽后同样安静，流水线卡在pending状态。

这些都是“温柔一刀”，不跳出来骂你，但工作效率立刻受影响。建议团队每周一看一眼用量仪表盘，别等全组瘫痪才找原因。

7. 综合评分与选型建议

7.1 综合评分表

基于五项维度打分，加权后的总分如下：

GitHub和GitLab并列总分第一，但它们的短板其实也明显：对国内网络和中文生态的支持不如CODING。如果团队全员在国内办公，我建议把CODING和GitHub互换位置来看。

7.2 四种团队画像与推荐组合

根据实测结果，我把读者分成四类，直接抄作业：

第一类：5人以内初创团队，追求生态、未来可能融入海外开源社区。首选GitHub Free。原因很简单：生态、集成、社区资源都是独一档，代码托管能力和审查体验足够优秀，免费额度在几款SaaS里最扛用。团队里配一个“小助手”专门管Actions额度，完全能支撑前6到8个月。

第二类：国内中小型公司，全员中文环境，需要正式项目管理流程。首选CODING基础版。它把代码托管、看板、迭代、CI、通知打通了，一个平台解决所有事，对不会折腾服务器的小团队最友好。注意它5人限制，超过5人就要评估是否升级付费。

第三类：有Linux服务器运维能力的团队，追求数据自主和无限成员。首选Gitea。或者“Gitea + 禅道”组合：Gitea管代码，禅道管流程。这套方案零授权费、无限仓库、无限用户，但需要有人维护服务器，适合有一定技术底子的团队。

第四类：重度使用Atlassian生态（尤其Jira）的团队。直接选Bitbucket Free。它的项目管理虽然拉胯，但和Jira的数据联动是最好的，可以用Jira的强大弥补Bitbucket的功能阉割。如果不用Jira，不要选它。

7.3 实测中的意外发现与避坑清单

最后写几条其他测评不太会提的实战细节：

• GitHub的免费组织仓库功能很容易被忽略，很多团队还在用“个人账号建共享仓库”的方式协作，权限一团糟。实际上创建一个Organization，把成员拉进去，免费版权限模型立刻清晰十倍。
• GitLab Free的400分钟CI看着少，但搭配“自托管Runner”后，跑流水线完全不消耗这400分钟。只需要一台小主机，装一个gitlab-runner，注册到项目里，CI就跑在自己的机器上，额度限制直接绕过，这种做法完全合规。
• Gitee的私有仓库数量限制，可以通过把开源项目设为公开来腾出额度，但千万别为了省额度把本该私有的代码公开，得不偿失。
• CODING的项目模板一定好好选，建错项目类型后，改起来需要迁移数据，很麻烦。
• Gitea部署后先开HTTPS，别裸奔跑HTTP。我们实测在内网裸奔没事，一旦暴露到公网，第二天日志里就会出现一堆扫描机器人的渗透尝试。
• 禅道部署时MySQL密码别用默认值，网上公开的默认密码攻击脚本太多了。这是我们在测试期间被攻破一次得到的教训。

这次测试做完，我最大的感受是：真正限制团队的往往不是工具价格，而是流程和习惯。GitHub和GitLab的免费额度已经比我五年前写博客时翻了好几倍，国产工具在项目管理体验上也逼近甚至局部超越了国际巨头。选型不需要一步到位，先跑起来，再根据痛点升级，这才是免费工具的正确使用方式。评测表就放在上面，照着抄就行。