Ask HN: GitHubの代替
Ask HN: Alternatives to GitHub
ここ数ヶ月、GitHubが継続的にダウンしています。代替手段に切り替えるべきでしょうか？
DSCI - http://deadsimpleci.sparrowhub.io - 軽量（Go言語で書かれた単一バイナリ）- CIランナー組み込み（podman / docker）- パイプラインは一般的なプログラミング言語で書かれています - YAMLの狂気はありません - Perl/Python/Bash/Raku/Powershell/Php/Golangのサポート - コードエディタ
GitLabとGiteeをチェックしてみることを検討してみてください。
HNでの議論
139- plqbfbv
セルフホストのGitLabを提案している皆さんへ：私たちは会社で6年以上それを使ってきましたが、常に順風満帆というわけではありません。独自のランナーを持ち、業務開始前に毎日Dockerイメージを自動アップグレードするようにしていました。ほとんどは本当にうまく機能しましたが、Dockerのアップグレードをロールバックしなければならないことが数回あったり、同梱のpg_shared_buffersがデフォルトで1MBに設定されていて、大規模なインスタンスではスキーマのアップグレードが不可能になったことが一度あったり、メジャーバージョンがパイプラインの期待を壊して、一度に200以上のリポジトリをアップグレードせざるを得なくなったり（その後はメジャーにピン留めしました）という例外がありました。最近では、重大/高脆弱性のため、ほぼ毎週「緊急パッチ」のニュースレターを受け取っていましたが、これはおそらくLLMがコードを調べてバグを特定した結果だと思います。とはいえ、GHに移行しなければよかったと思います。私たちのセルフホストインスタンスは、おそらく少し遅い（管理部門がコストを節約している）にもかかわらず、ダウンタイムがはるかに少なく、もう少し手間がかかりました。GHはEnterprise対応とは程遠く、全体的にダウングレードのように感じます。GLの方がアクセス粒度が良く、ドキュメントも良く、統合も優れており、UIが多くの注目を集めていることがはっきりとわかります（ただし、新しいアカウントでサイドバーの迷路のようなサブメニューに適切な項目をピン留めするのに10分かかりますが）。また、必要ならコードを見て手伝うこともでき、Dockerマウントを介してイメージにパッチを当てたバージョンを提供することもできます。本当に小規模なチーム（50〜100人まで）向けにGitLabをセルフホストすることを検討しているなら、事前に準備をしてください。
- rhdunn
何を求めているかによります。
1. GitHubのように動作し、感じられるものが欲しいですか？ -- ForgejoとGiteaがこれに適しています。
2. 手間をかけずにgitリポジトリをホストする場所が欲しいですか？ -- GitLab、CodeBerg、その他があります。
3. 独自のホスティングインフラを持っていますか？ そのホスティングプラットフォームやローカルハードウェアでgitoliteとCGit/GitWebを使用できます。
4. リポジトリをホストするだけなら？ -- GitoliteはSSH/認証/リポジトリ作成に役立ち、CGitやGitWebをフロントエンドに使用できます。
5. GitHub Actionsのようなものが必要ですか？ -- GitLab、Forgejo、GiteaはCIを提供します。または外部のCIインフラを使用します。
6. 課題追跡と管理が必要ですか？ -- GitLab、Forgejo、Giteaがこれらを提供します。Jiraからカンバン（Trelloを含む）、Markdown（Obsidianなど）まで、代替手段があります。
- icy
https://tangled.org！創業者兼CEOです。私たちはゼロから新しいフォージを構築しており、完全にフェデレーションされています。gitリポジトリをCIランナーと一緒に自分のインフラでホストできます。また、かなり便利な機能セットもあります（自分で言うのもなんですが）：スタックPR、NixベースのCI（希望する場合）、そしてあなたとあなたのエージェントのための完全にオープンなプロトコル（https://atproto.com）です。ご質問があればお答えします。
- polycaster
- mariocesar
別のスレッドで答えたのですが、すでに大規模なGitHub組織を運営しているなら、GitLabは機能の面で最も近い代替手段です。大きな利点は、セルフホストできるオープンソースのCommunity Editionもあることです。
- axegon_
数ヶ月前にすべてをcodebergに移行しました（そして毎年の寄付スケジュールを作成しました）。私はもともとgithubの大ファンではありませんでしたが、最終的に捨てる決心をさせたのは、githubが私に尋ねもせずにcopilot/chatgptを押し付けてきたことでした。Codebergはそれに対して明確な立場を取っており、私は完全にその立場に賛成です。さらに、自宅のサーバーで非常に重要なもののためにforgejoを立ち上げましたが、それは素晴らしいです。
- gritzko
GitHubの代替が別の中央集権的なフォージであるという前提には強く反対します。Git自体は完全に分散化されており、元々のLinuxカーネル開発プロセスもそうでした。どうして人々がすべての卵を、時々しか利用できないサービスに一つのかごに入れてしまったのか、私には理解できません。卵を別のバケツに移すことは解決策ではありません（Microsoftがサーバー不足というわけではありませんが）。単一障害点が問題なのです。配管、磁器、そして「github」層があります。「github」の部分も分散化されなければなりません。そうすれば、特定のフォージを使うことは、必要性ではなく利便性の選択になります。https://replicated.live/blog/crdt
- quaintdev
- hinkley
私は、すべてがgithubにあるエコシステムの一部であるため、窮地に立たされています。GHが、私がメンテナンスしているプロジェクトに対して新しいissueやPRが提出されたときに、通知設定が通知を受け取るべきことを示しているにもかかわらず、それを表示してくれないことには不満ですが、少なくともAtlassianではありません。私はいくつかのライブラリの主要なアーキテクチャ変更に取り組んでいて、初期の間違いを修正したりパフォーマンスを改善したりしていました。それらのうちの1つが、死んだツールAを使用していて、それはさらに死んだツールBの上に構築されていることに気づきました。新しいBを構築している人を見つけ、私は新しいAを作り、そのプロジェクトにそれを組み込むことを提案しました。それはうまくいったので、それを私が貢献していた他のプロジェクトにも統合しました。現在は私もメンテナーです。そして「新しいB」にも、彼のライブラリの意図を彼が考えていたよりも推し進め、公開APIの約20％と内部の約5％を貢献しました。それらのプロジェクトの1つは巨大で、私はそのサブプロジェクトにいるだけです。それらすべてを移行させることは決してできないでしょう。そして、GitHubと^GitHubの組み合わせは、issueとPRを把握するために必要な雑務の量を2倍以上にします。そして、それが罠なのです。
- ukd1
gitlabとgiteaを使ったことがあります。giteaは高速で、管理が簡単で、実際に必要なことはすべてできますが、機能はそれほど充実していません。