自建Git服务器

news2024/9/20 16:48:59

Gitea - Git with a cup of tea是一个国外团队基于国内一位大牛写的gogs开源项目（Go语言开发）二次开发的轻量Git社区，其稳定性非常好，而且是非常轻量级在个人亲测在1核1G的centos7主机上1个月不重启依然稳定运行，引用gogs官网的说法：”一个廉价的树莓派的配置足以满足 Gogs 的最低系统硬件要求。有些用户甚至还将 Gogs 运行在 NAS 设备上“。而且它支持几十个国家语言，横跨linux和windows等多平台，支持自定义界面皮肤模板。文档全面完美支持简体中文。但是新手安装可能会比较折腾所以花了几天时间针对宝塔面板写了这个第三方插件。

应用名称：GiteaForBt

价格：免费试用

作者：偻儸小卒 [爱折腾的小码农]

功能介绍：Gitea是一款支持多国语言的轻量级开源Git社区,内存需求512M以上均可完美运行

支持版本：Centos7 (64位系统)，Ubuntu 16.04 (64位系统)[18.04未测] [32位也是支持的由于市面上基本都是64位系统了所以也没做过多测试]

安装方法：升级到最新的内测版本。在第三方插件里安装

使用教程：1.更新到最新测试版宝塔,选择第三方插件找到GiteaForBt点击购买安装.

作为可以自己部署的 Git 托管服务器方案，Gitea 与 GitLab 有很多相似之处：有着和 GitHub 相似的仓库界面，一样有着基本的 Git Server 功能，一样同时支持 http(s) 与 ssh，一样支持 Issue 和 Pull requests……

Gitea 是完全开源免费的项目，而 GitLab 有着开源并免费的版本 GitLab CE，也有付费并有闭源功能的 GitLab EE。它们也都提供了由各自的官方托管版网站，你可以前往 gitea.com 与 gitlab.com 体验它们的用法。

这些最基础的东西双方都很相似，只看双方提供的功能对比表很难感受出它们有多大差别，但在实际部署它们后，你可以很直观地感受到它们骨子里就是不同的，它们之间的区别就和 com.sun.net.httpserver 和 Spring 全家桶一样，是单一功能的库与一个生态的区别。

Gitea 是一个功能较为单一的 Git 托管服务器，所有功能都围绕着 Git 托管而来，而且给出了较高的可定制性。在部署 Gitea 的时候，我很明确自己的目的是实现 Git 托管功能，部署后我再根据自己的需求去组合其他工具来满足我的工作流。

GitLab 则是一个大而全的解决方案整合，将 Git 托管、持续集成/部署等功能做在了一起，试图解决你的所有需求。在我部署它之后，我需要探索它的功能，学习它的工作流，适应它来完成我的工作。

资源占用

作为 Git 托管服务器使用时，Gitea 资源占用明显要低得多。

静态硬盘占用上，Gitea 核心是一个 100 MiB 上下的可执行文件，外加上作为必要依赖的 Git（如果内置 SQLite 不够的话也需要单独部署一个 MySQL 或者 PostgreSQL 做数据库），而 GitLab 光 Docker image 大小就 GiB 级了……不用我多说，截一下 GitLab 的日志文件夹就知道这玩意有多重量级了：

$ ls ./gitlab/logs
alertmanager     gitlab-kas    gitlab-workhorse  nginx              prometheus   redis           sshd
gitaly           gitlab-rails  grafana           postgres-exporter  puma         redis-exporter
gitlab-exporter  gitlab-shell  logrotate         postgresql         reconfigure  sidekiq

我断断续续跑了两天，这日志就快 200MiB 了……

内存方面，我这里 Gitea 日常占用内存通常在几百 MiB 浮动，而 GitLab 的 Docker 容器目前内存占用是 14GiB。

GitLab CPU 占用率（相对于一个核心计算）日常待机在 35% 上下，而 Gitea 通常是 0.2% 左右。（这些都是日常无负载状态下的情况，如果有机会的话我试试进一步比较，现在正在停用 GItea，懒得折腾了。）

网站配置

Gitea 大部分配置都要通过修改 app.ini 并重启 Gitea 服务器来应用，后台管理面板基本没有可修改的配置，不能进行配置热修改。

GitLab 部分网络相关的配置（域名，端口，代理，邮箱等）需要修改 gitlab.rb 并重启 GitLab，剩下的大多选项都是在管理员面板里通过 Web UI 进行热修改并及时生效。

对于要稳定运行的 Git 托管服务器来说，Gitea 每次修改配置后想要生效都要离线一段时间，好在 Gitea 启动很快，我这里从启动到能正常访问大概只要 10 秒钟（数据库跑在另一个容器里，没有计算它的启动时间），而 GitLab 启动一次要一分多钟，但由于 GitLab 大部分配置都是热修改，除了最开始部署时需要修改配置，运行中基本没有重启的需求。

想要自定义页面布局在 GitLab 上非常困难，除了首页内容可以通过管理面板修改外，剩下的地方似乎都无法用常规手段修改。Gitea 放开了很多 tmpl 文件可配置，我想要给站点每个页面底部添加一条链接，自己提供一个 extra_links_footer.tmpl 就能完成，但在 GitLab 我是没有找到什么好办法去实现。（似乎能改 /var/opt/gitlab 里的东西来修改布局，但我改了这个文件夹里的一些配置后再重启后，我修改的地方都被还原了，有空再做进一步的探索。）

另外有一点就是，Gitea 内几乎所有链接都在使用基于 ROOT_URL 的绝对链接，所以基本绑死在这个 ROOT_URL 上，配置好后基本没办法用多个域名访问同一个 Gitea。准备使用内网穿透的用户要注意一下这个问题，很多内网穿透服务分配给用户的都是非标准端口，如果想在内外网都能良好访问自己的 Gitea 服务器，最好让 Gitea 内网的端口与公网端口一致，不然很多麻烦事情。

GitLab 会检测你用来访问 GitHub 所用的域名，而且很多地方都会根据这个更改显示，不会因为用不同于 external_url 的地址访问而出现问题，这方面问题会比 Gitea 少很多。（注意一下，如果你在 external_url 中写了带端口号的地址，GitLab 的侦听端口也会跟着变更。不想改侦听端口的话记着覆盖 nginx['listen_port'] 设置）

隐私保护

隐私保护方面我觉得是 Gitea 最值得诟病的问题，也是我转而投向 GitLab 的主因。

Gitea 的一些功能需要 GitHub TOKEN 实现（譬如从 GitHub 导入私有项目等），GitHub TOKEN 作为用户隐私，本身应该受到良好保护，但我在实际使用过程中发现，目前版本（v1.16.4）的 Gitea 有严重的安全问题：

当用户正在进行使用 GitHub TOKEN 访问 GitHub 仓库的任务时，包含了 GitHub TOKEN 的 URL 直接明文出现在管理后台中，管理员可以轻松的从后台看到这些隐私信息：

这应该开发者考虑不周造成的问题，相对而言能明显感受到 GitLab 要更关心用户的隐私保护问题，涉及到隐私信息时都高度敏感，在不修改服务器本身的情况下，管理员也无法触及它们。（当然在管理员能接触到 GitLab 服务器的情况下，依然可以通过篡改服务器来窃取用户隐私，所以对第三方托管的服务器并不能无保留的信任。）