企业官网建设流程全解析

自托管Git平台怎么搭？一台 2G 内存的小机器跑通代码托管与 CI/CD 自动部署

【免费下载链接】onedevThe Unified and Autonomous Development Platform项目地址: https://gitcode.com/gh_mirrors/on/onedev

凌晨一点，老周在群里发来一张监控截图：自建的 GitLab 实例又内存溢出了，构建队列整整卡了四十分钟。这已经不是他头一回为"代码托管 + 流水线"这对组合买单——用云上的仓库，私有代码放出去心里不踏实；自建一套吧，Git 服务、CI/CD、看板各装各的，维护成本比开发任务还高。直到他换上 OneDev，这个把自托管Git平台、CI/CD 流水线和项目管理看板整合进同一个进程的开源项目，事情才真正变得简单。

如果你也在"仓库放哪、流水线怎么跑"之间反复横跳，这篇就为你写的。我们不聊概念，直接拿一个小项目，从安装一路走到自动部署。

为什么自托管Git平台值得你重新考虑

先别急着下单服务器，我们把账算清楚。

团队规模一大，工具就开始分裂：代码在云仓库，构建在另一个 CI 服务，任务管理又在第三个系统。每次代码改动，要在几个界面之间来回跳转，还经常出现"代码合了但流水线没触发"的尴尬。更现实的是数据主权——私有代码放在第三方平台，出点合规问题没人替你兜底。

自托管Git平台解决的就是这两件事：一是把 Git 仓库、CI/CD、问题跟踪整合进同一套系统，减少工具之间的摩擦；二是数据完全落在自己手里，备份、迁移、审计都有主动权。OneDev 在这条路上走得挺远——分支保护、代码搜索、内置 AI、包仓库全做进了同一个安装包，不用你像拼乐高一样自己拼凑工具链。

你可能会问：自托管是不是都很吃资源？OneDev 的官方参考配置是 1 核 2G 内存就能带起中小型项目，这一点后面我们会实测验证。

安装自托管Git平台的两条路线

动手之前先说结论：安装 OneDev 有两条路线，要么用 Docker 三分钟跑起来，要么从源码启动开发模式。

路线一，Docker 快装。机器上有 Docker 的话，一条命令就能拉起服务：

docker run -it --rm -v /var/opt/onedev:/opt/onedev -p 6610:6610 -p 6611:6611 1dev/server

6610 是 Web 端口，6611 是 SSH 端口，/var/opt/onedev是数据目录。浏览器打开http://localhost:6610，按引导填好管理员账号，一个能用的仓库服务就上线了。

路线二，源码跑开发模式。想改代码、想加插件，或者想看看这个项目内部怎么组织，就克隆仓库用开发模式启动：

git clone https://gitcode.com/gh_mirrors/on/onedev cd onedev ./dev.sh run

仓库根目录的dev.sh支持run、build、test等命令，开发模式下改完 Java 代码还能热加载，很适合想做二次开发的朋友。如果你好奇它的开发约定，development.md 写得很清楚，上手前翻一遍能少走不少弯路。

如何搭建CI/CD流水线：三个作业跑通自动部署

服务起来之后，我们建一个 demo 项目，推两行代码上去，然后把持续集成配置起来。这一步是整个流程的核心，也最能体现"可视化编排流水线"和传统 YAML 写流水线的区别。

OneDev 的构建作业可以直接在网页上编排，不需要先背语法。进入项目的构建页面，你可以像搭积木一样添加作业：比如一个 demo 项目拆成build frontend、build backend、build product三个作业，再在右侧的 Dependencies & Services 面板里声明它们之间的依赖关系和所需服务。

配置持续集成时有几个关键点值得留意：

• 作业依赖：声明build product依赖前两个作业，只有上游成功它才启动，天然形成"构建→打包"的递进关系。
• 矩阵作业：同一套逻辑跑多个参数组合（比如不同 Node 版本），不用复制粘贴作业。
• 缓存管理：npm 或 Maven 依赖命中缓存后，重复构建能省下大把时间。

配置完成后，每次git push都会自动触发流水线，这就是持续集成最朴素也最重要的闭环。OneDev 内置了 Node、Python、Java、Go 等常见框架的模板，多数项目不用从零写脚本，选个模板改改参数就行。

执行器与自动部署：从"跑通"到"跑得动"

流水线定义好了，谁来执行？这一步是新手最容易懵的地方。OneDev 用"执行器"（Executor）抽象了运行环境：默认自带的服务器 Docker 执行器开箱即用地跑容器化任务；等构建量大起来，可以加 Kubernetes 执行器横向扩容，或者用 Agent 把任务分发到不同机器上。

自动部署这步也不难。把打包产物推进 OneDev 内置的包仓库，后续的容器镜像、NPM 包、Maven 构件就都有了统一出口，CI/CD 产物和发布流程因此天然连通：

那么问题来了——流水线卡在编译这一步怎么办？OneDev 的 Web 终端能让你直接钻进正在运行的作业里看环境、试命令，甚至手动暂停脚本现场排查，不用再靠"加日志→重跑"的笨办法反复试错。

自托管平台安装与运维的常见坑

功能讲完，说点实在的。下面这几个坑是我折腾自托管Git平台时真实踩过的，提前知道能省一天时间。

坑一：端口和反向代理没理清。6610 是 Web、6611 是 SSH，如果走 Nginx 反代，别忘了把 WebSocket 升级头配好，否则代码对比、Web 终端这类实时功能会时好时坏。

坑二：执行器环境和开发环境不一致。"我本地明明能编译"多半是构建环境没固定下来。建议直接用 Docker 执行器，把 JDK、Node 版本写进镜像，杜绝"换个机器就挂"。

坑三：权限配得太粗或太细。OneDev 的权限模型支持按用户/组、按分支、甚至按特定文件路径来设保护规则。建议从"主干分支必须通过 CI 才能合并"起步，别一上来就全开。规则的具体实现可以翻 server-core/src/main/java/io/onedev/server/security/，灵活程度比想象中高。

坑四：高可用不等于备份。OneDev 支持把项目复制到多台服务器组成集群，界面里能直接看到各副本的同步状态：

但如果只有单机，先做好数据目录的定期备份，别把"多副本"当成唯一保险。集群化部署的配置模板在 server-product/helm/，走 Kubernetes 的朋友可以直接参考。

坑五：升级前先看兼容性说明。项目在 server-product/system/incompatibilities/incompatibilities.md 里维护了版本间的破坏性变更清单，升级前扫一眼，比踩完坑再回滚省事得多。

什么场景适合它，什么场景建议换别的

说了这么多，最后帮你做个判断。

如果你的情况符合下面任意一条，OneDev 值得认真试用：

• 私有代码需要完全掌握在自己手里，又不想在 Git 服务之外再养一套独立的 CI 系统；
• 团队已经用看板管任务，希望提交、构建、发布能自动联动任务状态；
• 机器资源有限，想在低配服务器上跑起全套 DevOps 工具链；
• 想用内置 AI 做代码评审、排查构建失败，又不想把代码喂给外部服务。

反过来，也有几种情况建议三思：

• 团队深度绑定某个云厂商的托管服务，迁移成本远大于收益；
• 对流水线有极其特殊的定制需求，而团队没有意愿维护开源代码；
• 现有工具链跑得很稳，"能不折腾就不折腾"也是一种正确。

从"GitLab 卡死"到"一台 2G 内存的机器跑完整套流程"，老周现在把仓库、流水线和看板都搬到了 OneDev 上。工具不在多，能把从git push到自动部署这条路走通、走得稳，就值回票价了。如果你也在为同样的烦恼发愁，不妨照着上面的步骤试一次，两个小时后你大概也会发出和老周一样的感叹：原来自托管Git平台可以这么省心。

【免费下载链接】onedevThe Unified and Autonomous Development Platform项目地址: https://gitcode.com/gh_mirrors/on/onedev