I like GitLab | WhileForLoop

摘要

本文是一位开发者对 GitLab 的使用心得分享。作者最初因 GitHub 私有仓库收费而转向免费的 GitLab，并逐渐形成了依赖其 CI/CD 和容器镜像仓库的工作流。尽管 GitLab 存在界面响应慢、功能过于臃肿等问题，但对于管理十几个私有项目而言，其免费且功能完善的特性仍具有很高的实用价值。作者最终形成了私有项目用 GitLab、公开项目用 GitHub 的双平台策略。

内容框架与概述

文章开篇回顾了作者选择 GitLab 的历史背景：在 GitHub 私有仓库还需付费的年代，GitLab 提供了免费方案，成为小型项目和实验代码的理想归宿。即便后来 GitHub 也推出免费私有仓库，作者已经围绕 GitLab 建立了完整的开发流程，迁移成本过高。

随后作者重点介绍了两个核心功能。一是每个项目自带的容器镜像仓库，无需额外注册 Docker Hub、无需担心拉取频率限制，与现有认证体系无缝集成。二是 CI/CD 系统，通过 .gitlab-ci.yml 实现配置即代码，免费的共享 Runner 足以应对大多数工作负载，自建 Runner 也很简单。

文章后半部分坦诚讨论了 GitLab 的不足：Web 界面响应速度较慢，功能过于繁杂导致新手难以上手。但作者认为这也是双刃剑——当需要 NPM 私有仓库或安全扫描时，功能已经内置。最终，作者阐述了自己的工作流哲学：GitLab 是私密的数字工坊，GitHub 则是对外展示的窗口，两者各司其职。

核心概念及解读

Container Registry（容器镜像仓库）：GitLab 每个项目内置的 Docker 镜像存储服务，免去了单独管理 Docker Hub 账号和访问令牌的麻烦，每项目 10GB 配额对大多数场景绑绑有余。

CI/CD as Code（配置即代码）：通过版本控制的 .gitlab-ci.yml 文件定义构建流程，使得流水线配置可追溯、可复现，六个月前的配置状态一目了然。

Shared Runners（共享运行器）：GitLab 提供的免费 CI 执行环境，速度虽不快但稳定可靠，对于个人项目已足够使用。

Feature Overload（功能过载）：GitLab 试图成为一站式 DevOps 平台，导致侧边栏菜单冗长、学习曲线陡峭，但也意味着潜在需求随时可被满足。

双平台工作流：将私有实验项目放在 GitLab、公开项目放在 GitHub，兼顾隐私保护与社区可见性，各取所长。

原文信息

此摘要卡片由 AI 自动生成