问HN：GitHub的替代方案

# 询问HN：GitHub的替代方案 来源：https://news.ycombinator.com/item?id=49331033 https://news.ycombinator.com/vote?id=49331916&how=up&goto=item%3Fid%3D49331033 致所有推荐自托管GitLab的人：我们公司在公司里运行了6年多自托管GitLab，过程并非总是一帆风顺。我们配置了自己的运行器，并设置了每日业务开始前通过Docker镜像自动升级。大多数时候它运行得非常出色，除了少数几次Docker升级需要回滚，或者有一次默认的pg_shared_buffers被设为1MB，导致大型实例的schema升级无法进行，或者某个主版本升级打破了流水线预期，迫使我们一次性升级200多个仓库（之后我们便锁定了主版本）。最近，我还几乎每周都会收到一封关于严重/高危漏洞的"关键补丁"通讯，我只能推测这是大语言模型扫描代码后发现的bug。 话虽如此，我真希望我们没有迁移到GitHub。尽管我们的自托管实例可能稍微慢一些（管理层想省钱），并且需要更多维护工作，但它的停机时间*远*少于GitHub——GitHub根本不够企业级水平，整体感觉像是一种降级。GitLab在访问控制粒度、文档、集成方面都更好，而且你可以明显看出UI投入了很多精力（尽管新账户需要花10分钟在侧边栏这个迷宫般的子菜单中固定正确的项目）。你还可以查看代码并在需要时提供帮助，或者简单地通过docker挂载为你的镜像提供修补版本。 如果你真的考虑为小型团队（最多50-100人）自托管GitLab，至少准备一台16GB内存（最好32GB）、4个核心和优质SSD的机器，并且需要一个小团队（1-3人）来妥善维护或随时能投入处理。对于运行器，使用一个小的k3s集群是理想的选择，这样可以充分利用你能投入的所有资源，而不用担心管理运行器的状态/配置。 https://news.ycombinator.com/vote?id=49332644&how=up&goto=item%3Fid%3D49331033 设置自定义GitLab运行器起初可能很麻烦！我们为多个使用GitLab.com托管仓库的客户项目多次遇到这种情况。这就是为什么我和同事最近构建了"GitLab 运行器即服务"[0]——只需使用您的自托管GitLab或GitLab.com账户登录，添加流水线运行器只需一键操作！在底层，我们为您为运行器配置了一台Hetzner机器，并自动将您的GitLab组或项目连接到它。欢迎提供反馈！ [0]https://rocketrunner.io/ https://news.ycombinator.com/vote?id=49332780&how=up&goto=item%3Fid%3D49331033 我还要说，GitLab运行器是GitLab中最容易出问题的部分，需要进行一些细致的管理。如果我从头开始搭建，我会考虑用GitLab做源代码管理，但使用托管服务进行CI。 https://news.ycombinator.com/vote?id=49332295&how=up&goto=item%3Fid%3D49331033 同意。GitHub Actions感觉像是某人在蘑菇幻觉中创建的科学项目。说真的，你只是想要一个在运行器中执行shell脚本的东西。 https://news.ycombinator.com/vote?id=49332052&how=up&goto=item%3Fid%3D49331033 如果你熟悉GitHub Actions，你会立即理解Forgejo Actions。这是有意设计的。虽然有一些差异，但对我来说，不足以引起任何争议。 如果你有高级用例，可能会更沮丧，但我目前想不出有什么具体例子。我想我最大的抱怨是他们没有通过API暴露Action日志，所以我无法在CLI层面构建相关工具、将其输入大语言模型，或者在不使用网站的情况下更快地诊断出现的问题。 https://news.ycombinator.com/vote?id=49332181&how=up&goto=item%3Fid%3D49331033 Forgejo v16中添加了一个用于访问Actions日志的基础API。`/api/v1/repos/{owner}/{repo}/actions/jobs/{job_id}/logs` https://news.ycombinator.com/vote?id=49332035&how=up&goto=item%3Fid%3D49331033 你可以使用任何想要的CI/CD。GitHub受欢迎的唯一原因是它对公共仓库免费。 但Forgejo确实有一个类似GitHub的CI/CD。如果你真的在乎好的CI/CD，你应该尝试一些替代方案，并根据你的需求决定哪个最合适。 https://news.ycombinator.com/vote?id=49332647&how=up&goto=item%3Fid%3D49331033 > GitHub受欢迎的唯一原因是它对公共仓库免费。 它对私有仓库也免费，我两者都有。Codeberg不太喜欢私有仓库，所以很遗憾我无法把所有东西都移到Codeberg。我可能会在某个VPS上设置一个Forgejo。 https://news.ycombinator.com/vote?id=49332365&how=up&goto=item%3Fid%3D49331033 除了在CI/CD中做尽可能少的事之外，我没有其他具体建议，相反，应在构建系统或被CI/CD调用的脚本中做尽可能多的工作。这样，你可以减少迁移时的工作量，或者在需要时本地运行。 https://news.ycombinator.com/vote?id=49332438&how=up&goto=item%3Fid%3D49331033 通过SSO直接与drone.io集成。 在内部网络上自托管两者。从技术上讲是旧版的Gitea，也就是Fork前的Forgejo。 https://news.ycombinator.com/vote?id=49331516&how=up&goto=item%3Fid%3D49331033 我在另一个帖子里回答了这个问题，如果你已经有一个大型的GitHub组织，GitLab在功能上是最接近的替代品。 一个很大的优点是，它也有一个开源社区版，你可以自托管。 https://news.ycombinator.com/vote?id=49332998&how=up&goto=item%3Fid%3D49331033 我第一次听说这个，但他们似乎是一个年轻、聪明、充满活力的团队，正朝着良好的方向发展。选择atproto很有趣，符合他们面向社交的目标。 https://news.ycombinator.com/vote?id=49332807&how=up&goto=item%3Fid%3D49331033 为私有仓库设置和运行这个有多容易？ 它看起来有很多很酷的功能——堆叠式PR、Jujutsu支持、在Nix虚拟机中进行CI。但我从未尝试过，因为听起来（至少默认情况下）它像是某种去中心化的、点对点的公共事物。 https://news.ycombinator.com/vote?id=49333031&how=up&goto=item%3Fid%3D49331033 不确定是否有人已经提到，但我过去也使用过Bitbucket，发现它非常易于使用，提供的功能与GitHub类似。 https://news.ycombinator.com/vote?id=49331969&how=up&goto=item%3Fid%3D49331033 我使用过GitLab和Gitea；Gitea更快，更容易管理，能满足我实际需要的一切，尽管功能不如GitLab完整。 https://news.ycombinator.com/vote?id=49332683&how=up&goto=item%3Fid%3D49331033 我是Gitea的项目负责人之一。我很想知道你认为Gitea相比GitLab缺少哪些功能？我们正在进行一些待办事项梳理，非常感谢你的反馈 :) https://news.ycombinator.com/vote?id=49332095&how=up&goto=item%3Fid%3D49331033 几个月前我将所有内容迁移到了Codeberg（并制定了年度捐赠计划）。我从来不是GitHub的狂热粉丝，但最终推动我放弃它的，是GitHub在我从未要求的情况下，强行向我推送Copilot/ChatGPT。Codeberg对此有明确的立场，而我完全支持这个立场。 此外，我在家里的服务器上启动了Forgejo用于存放非常重要的东西，效果很棒。 https://news.ycombinator.com/vote?id=49332600&how=up&goto=item%3Fid%3D49331033 注意：如果你切换的唯一原因是正常运行时间，那么Codeberg会让你大失所望。 他们自己的网站报告的两周正常运行时间是"1个9"https://status.codeberg.org/status/codeberg，我怀疑如果你使用人们喜欢为GitHub发布的（非常糟糕的）全产品服务正常运行时间衡量标准，整体服务将是"0个9"。 https://news.ycombinator.com/vote?id=49332767&how=up&goto=item%3Fid%3D49331033 切换的原因是为了不被强行灌输那些垃圾内容，即使只是浏览时也是如此。我有几个已发布的项目，还有几个计划将来开源，所以就这个目的而言，Codeberg做得非常出色。至于工作——唉，我在企业环境中使用公司服务器上的内部仓库，所以这个问题就不那么大了。 https://news.ycombinator.com/vote?id=49332311&how=up&goto=item%3Fid%3D49331033 Codeberg用于开源项目，Forgejo用于私有项目（以及垃圾内容，如果你喜欢的话），这是赢家的做法。 https://news.ycombinator.com/vote?id=49332474&how=up&goto=item%3Fid%3D49331033 老实说，我不喜欢那种东西：对我来说，Forgejo是用于那些我不想让其离开我公寓范围的东西。 https://news.ycombinator.com/vote?id=49332043&how=up&goto=item%3Fid%3D49331033 我强烈不同意GitHub的替代方案是另一个中心化代码托管平台的假设。Git本身就是完全去中心化的，最初的Linux内核开发过程也是如此。人们怎么会把他们所有的鸡蛋都放在一个间歇性可用的服务篮子里，这让我无法理解。把鸡蛋搬到另一个篮子里不是解决方案（微软又不缺服务器）。单点故障才是问题。存在底层机制、应用层和“GitHub”层。“GitHub”这一层也必须去中心化。那么，使用特定的托管平台将成为便利性的选择，而非必需。https://replicated.live/blog/crdt https://news.ycombinator.com/vote?id=49332868&how=up&goto=item%3Fid%3D49331033 哦，原因其实很简单： 1. 人们不喜欢基于邮件的补丁流程。 2. GitHub让一切变得极其简单，而且免费。许多开源项目得以蓬勃发展，因为GitHub既易于使用，又让跨仓库协作变得轻松。 3. 极少数人*真正*关心去中心化。只要你在自己的机器和GitHub上都保存了仓库的完整副本，很难说去中心化能给你带来什么好处。 4. 大多数人也不想自托管Git服务器。 https://news.ycombinator.com/vote?id=49331807&how=up&goto=item%3Fid%3D49331033 自托管GitLab一直对我很好，它能够扩展，并且只要你持续关注，其攻击面是可控的。 更新的应用正在迁移到Google Cloud Secure Source Manager（因为我们使用Google Cloud并使用骨干网认证，这样更有意义，管理起来也更少）。 https://news.ycombinator.com/vote?id=49332483&how=up&goto=item%3Fid%3D49331033 我最近将私有项目迁移到了Gitoro，但还没有什么实质性意见。它对我来说可以用，速度快，没什么可抱怨的。只是在这里提一下作为欧盟托管的替代方案。 https://gitoro.com/ https://news.ycombinator.com/vote?id=49331950&how=up&goto=item%3Fid%3D49331033 我使用Forgejo + Gitea作为我的家庭代码库，然后对于任何我想用自己运行器分享的内容，使用Tangled。 我自托管Lore用于我的游戏开发项目。 https://news.ycombinator.com/vote?id=49331163&how=up&goto=item%3Fid%3D49331033 DSCI - http://deadsimpleci.sparrowhub.io/ - 轻量级（用Go编写的单个二进制文件） - 内置CI运行器（podman / docker） - 流水线使用通用编程语言编写 - 没有YAML的疯狂 - 支持Perl/Python/Bash/Raku/Powershell/Php/Go - 代码编辑器 https://news.ycombinator.com/vote?id=49331402&how=up&goto=item%3Fid%3D49331033 Forgejo棒极了。Codeberg是一个托管实例；取决于你开发什么，它可能适合你，也可能不适合。但Forgejo堆栈本身作为自托管方案相当轻量，使用起来非常快，并且易于导航。 https://news.ycombinator.com/vote?id=49332394&how=up&goto=item%3Fid%3D49331033 > 取决于你开发什么，它可能适合你，也可能不适合。 我认为如果你的项目是自由/开源的（编辑：并且你不使用大语言模型/AI），Codeberg至少是一个好的起点。如果你觉得项目超出了它的能力范围，可以迁移到自托管实例，但我认为即使是大型项目，你也完全可以只自托管CI运行器。 别忘了捐赠哦 https://donate.codeberg.org/ https://join.codeberg.org/ https://news.ycombinator.com/vote?id=49331685&how=up&goto=item%3Fid%3D49331033 我最喜欢的两个是sourcehut（它有*出色*的CI，并且不是试图成为GitHub的克隆）和Codeberg（从GitHub迁移的路径稍微更直接一些） [0] sr.ht [1] codeberg.org https://news.ycombinator.com/vote?id=49331978&how=up&goto=item%3Fid%3D49331033 Sourcehut仍然需要通过邮件发送补丁而不是“拉取请求”吗？上次我查看时，这对我来说是决定性的障碍。 https://news.ycombinator.com/vote?id=49332085&how=up&goto=item%3Fid%3D49331033 > Sourcehut仍然需要通过邮件发送补丁 我猜这个问题的技术上正确答案是“是”。但Sourcehut有非常好的邮件列表支持，本质上相当于GitHub的拉取请求。 不过，我觉得你的问题措辞有点偏见……就好像我在问“GitHub是否仍然要求通过专有界面发送拉取请求，而不是直接发送补丁？” https://news.ycombinator.com/vote?id=49332416&how=up&goto=item%3Fid%3D49331033 我在一个便宜的VPS上自托管Forgejo，每小时通过borg备份到rsync.net。这是一个很棒的系统，似乎可以和GitHub相媲美，尽管我不是这两个平台上Actions的重度用户。我确实使用容器注册表。迁移过程很顺利，安装也很简单。我使用了docker安装方式。如果你不介意自己托管，Forgejo很棒。 https://news.ycombinator.com/vote?id=49332858&how=up&goto=item%3Fid%3D49331033 你可以考虑dsci，因为它的CI是内置的，并且直接使用通用编程语言作为一等公民。 https://news.ycombinator.com/vote?id=49331796&how=up&goto=item%3Fid%3D49331033 我目前主要使用GitLab，包括自托管和他们的托管平台。但我对Cursor Origin很好奇，等它上线时肯定会尝试一下。 https://news.ycombinator.com/vote?id=49331483&how=up&goto=item%3Fid%3D49331033 我本人在私人VPS上托管了一个Forgejo实例；到目前为止几乎不需要维护，除了保护它免受AI爬虫的影响[#1]。如果你不想自己麻烦，codeberg.org是一个Forgejo的公共实例。 [#1]: https://her.esy.fun/posts/0031-how-i-protect-my-forgejo-instance-from-ai-web-crawlers/index.html 我配置我的本地仓库同时推送到Github和我的Forgejo实例。对于我的私有项目，我不怎么使用CI（我的情况下本地测试就足够了）。 https://news.ycombinator.com/vote?id=49332706&how=up&goto=item%3Fid%3D49331033 很高兴听到这个消息！我是Gitea的项目负责人之一，如果你遇到任何问题，请随时加入我们的聊天室 :) https://news.ycombinator.com/vote?id=49332786&how=up&goto=item%3Fid%3D49331033 我最近开始使用Fossil，在这方面我非常满意。我怀念Git世界的一些东西（主要是magit以及它暂存diff中各个代码块的神奇能力），而且也有一些粗糙的地方，但我完全同意将维基和问题跟踪放在仓库内部是非常有意义的。Fossil的简洁对于任何必须从CLI使用Git的人来说都是令人耳目一新的。绝对值得任何犹豫不决的人尝试。 https://news.ycombinator.com/vote?id=49332905&how=up&goto=item%3Fid%3D49331033 工作流程的范式是不同的，这可能会让很多人不适应。 原则上，没有变基。分支名称是提交的永久属性。即使被放弃的分支也会永远可见。代码审查是事后进行的。 极其习惯Git工作流程的人可能会觉得这个范式令人疏远。