O GitHub está afundando
(dbushell.com)- Desde a aquisição pela Microsoft, a disponibilidade (uptime) do GitHub piorou visivelmente, e até a página oficial de status mostra números preocupantes, enquanto páginas não oficiais retratam uma situação ainda mais grave
- Com o uso excessivo do Copilot e a enxurrada de código ruim gerado por IA (slop), o GitHub está efetivamente fazendo DDoS contra si mesmo, enquanto bots e a economia de estrelas falsas corroem a confiança na plataforma
- Git é um sistema distribuído de controle de versão de código aberto e funciona sem o GitHub, então é preciso deixar de tratar GitHub como se fosse o próprio Git
- Existem várias forges Git alternativas, como Codeberg, Tangled, Gitea, GitLab e o Forgejo auto-hospedado, e a migração deve começar imediatamente
- Vários desenvolvedores renomados vêm publicando textos anunciando sua saída do GitHub, e reduzir a dependência do GitHub passou a ser uma tarefa de todo o ecossistema
Por que sair do GitHub
- O GitHub vem sendo criticado por ter piorado em disponibilidade e experiência de uso desde a aquisição pela Microsoft, e acredita-se que a página de status com falhas omitidas revele uma tendência pior do que a disponibilidade oficial
- O gráfico GitHub’s Historic Uptime é usado para mostrar que a média mensal de disponibilidade ficou instável após a aquisição pela Microsoft
- Depois de comprar o GitHub, a Microsoft ampliou sua linha de produtos relacionados ao Copilot, e o GitHub está tão afetado por “slop” que chegou a publicar sua própria atualização sobre problemas de disponibilidade
- Recentemente, vêm surgindo vários textos sobre abandonar o GitHub ou revisitar formas de desenvolvimento anteriores ao GitHub
Git ≠ GitHub
- GitHub virou sinônimo de “gerenciamento de código-fonte”, mas usuários demais ainda não sabem que Git não é GitHub
- Git e GitHub não são a mesma coisa, e a tecnologia central do Git é código aberto e distribuída, então todos os repositórios são equivalentes e podem funcionar sem um serviço centralizado
- Serviços centralizados são um produto da conveniência social; o GitHub originalmente era apenas uma ferramenta adicional útil, mas a Microsoft o transformou em uma dívida cara
- O efeito de rede é forte, mas a economia de estrelas falsas do GitHub não tem valor, e a plataforma está cheia de bots e slop
- O GitHub Actions é parte de pipelines de CI excessivamente complexos. Procurar outras soluções pode ser trabalhoso, mas é preciso se perguntar se ainda dá para confiar na estabilidade do GitHub
- O navio está afundando, então, mesmo que você não mova tudo de uma vez, é preciso começar o processo de migração imediatamente
Alternativas e formas de migração
- A rota de fuga mais próxima é migrar para outra forge Git centralizada: basta se cadastrar e fazer push do repositório para o novo upstream
- Alguns serviços podem automatizar a migração e até oferecer importação de issues, mas também é possível optar por deixar as issues no GitHub como estão
- Nenhuma das alternativas abaixo é perfeita; o ponto em comum entre elas é apenas não serem o GitHub
-
Alternativas de forges Git centralizadas
- Codeberg — projeto sem fins lucrativos e liderado pela comunidade, uma alternativa segura com histórico comprovado. É a principal instância do Forgejo
- Tangled — startup em estágio alfa, com integração ao AT protocol como proposta interessante. Vale considerar para projetos pessoais pequenos
- Gitea — oferece hospedagem Git gerenciada na nuvem e é o projeto original de código aberto do qual Codeberg/Forgejo se separou
- GitLab — voltado ao nível enterprise, pesado e confuso, mas pode ser uma opção adequada para decisões dentro de organizações
- Bitbucket — não é recomendado, mas ainda entra na categoria de “não ser o GitHub”
- Game of Trees, Radicle, Sourcehut — alternativas adicionais, que exigem pesquisa por conta própria
-
Auto-hospedagem
- Organizações ou pessoas podem auto-hospedar uma forge Git e também operar actions e releases
- A opção recomendada para auto-hospedagem é o Forgejo
- Há discussões sobre federação entre instâncias Forgejo, e o Tangled também publicou um texto sobre federação, mas isso não parece algo que vá se concretizar no curto prazo
- Se for necessário colaborar publicamente, é possível usar uma cópia enviada ao Codeberg
- Gitea e GitLab também oferecem opções de auto-hospedagem, mas o GitLab é relativamente muito mais pesado
- Não apenas o GitHub, mas também outras forges são separadas do próprio Git, e vale questionar se os recursos adicionais da forge são realmente necessários
- É possível usar Git diretamente só com SSH
git clone user@192.168.1.67:/path/to/repo
- A forma de colaboração é outra questão, mas se o Linux pode ser mantido trocando patches por listas de e-mail, então é difícil afirmar que isso seja impossível apenas por causa da escala
- Forges Git centralizadas podem ser um compromisso prático, mas é preciso sempre ter um plano de saída, considerando que elas também podem ruir como o GitHub
2 comentários
Considerando os recursos que oferece, é surpreendente que esteja entregando mais de 99%.
Comentários do Hacker News
Todo mundo quer culpar isso pela aquisição pela Microsoft ou por incompetência, mas olhando o material divulgado pelo GitHub, parece bem claro que, por causa da IA, a quantidade de código com commit no GitHub aumentou 10 vezes, e o impacto disso se espalhou por CI, Actions, coleta de código e toda a plataforma
O autor aponta para elementos esquisitos como o MS Copilot como causa, mas parece mais uma lista de coisas de que ele não gosta do que uma relação de causalidade
Enquanto isso, ignora o verdadeiro elefante na sala: a explosão de código causada por IA
A OpenAI lançou o GPT-3.5 em novembro de 2022, na prática dezembro, e esse tipo de programação com modelos de linguagem/agents em larga escala só começou a ganhar força de verdade em 2024, na prática mais perto de 2025
Então como explicar a má disponibilidade durante cerca de 4 anos após a aquisição, antes mesmo de começarem a falar de IA?
Tudo bem embarcar na crítica à Microsoft, mas não dá para ignorar o elefante na sala
Mesmo que amanhã apareça um substituto perfeito para o GitHub, o que impediria que milhões de linhas de código gerado por IA detonassem a infraestrutura dele também?
Hospedagem centralizada de código parece quase condenada pela IA. É parecido com o que acontece nas redes sociais
10 anos é muito tempo, e o resultado está aí
GitHub Actions, Copilot, e aquela busca por IA feia que nem dá para desligar. Sem falar na migração para o Azure
A Microsoft conseguiu estragar os efeitos de rede, e as falhas foram a gota d’água
Tem bases de código gigantescas internamente e cerca de 200 mil funcionários
Especialmente porque tomou decisões conscientes como tornar repositórios privados gratuitos, isso dificilmente serve como desculpa
Sempre que o GitHub cai, penso “alguém deve ter atualizado o Windows Server onde o GH roda e precisou reiniciar tudo”
Tenho 99% de certeza de que isso não é verdade, mas pensar assim me conforta e até me faz rir um pouco quando acontece uma falha
Hoje fui ver um repositório no GitHub
Cliquei no link “xxx commits” para ver o histórico e apareceu uma mensagem dizendo que eu caí no secondary rate limit e precisava esperar
Sou a única pessoa nesta rede que acessa o GitHub, e a conexão usa IP dedicado, não CGN
Aí a página carrega normalmente
Na prática, há anos isso é menos rate limit e mais uma recusa padrão, mas eles se recusam a ajustar a mensagem para refletir a realidade
“GitLab — nível enterprise quer dizer inchado e confuso, mas com cara de impressionar seu chefe. Se forem necessárias várias reuniões para escolher, é esse que você deve pegar.”
Engraçado
Até as tarefas mais simples têm uma UI complicada demais. Por exemplo, para aprovar um MR você basicamente precisa apertar um botão que é um menu; o diff é difícil de ler; e a ‘To-do list’ inclui até MRs já mergeados. Como isso pode ser uma tarefa acionável?
O problema de MRs já mergeados continuarem na ‘To-do list’ foi reportado há anos, e a melhora não parece rápida
Por outro lado, a rejeição ao Bitbucket me surpreende um pouco. A UI é muito simples e clara, e as pessoas novas na equipe sentem o mesmo. Com Script Runner dá para fazer coisas bem impressionantes, e ele lida bem até com repositórios enormes
O GitLab não é particularmente mais inchado ou confuso que o GitHub
Nem acho que dê para chamar isso de software enterprise de verdade. Se quiser ver isso, basta olhar para o Jira ou qualquer coisa feita pela Microsoft
Usamos GitLab self-hosted, e fui eu quem escolheu por ter git e registry de contêineres
Se você não usa a UI web com frequência, a interface realmente pode parecer confusa
Por 5 dólares por mês dá para hospedar um servidor e colocar vários projetos nele
O repositório não vai ganhar um milhão de estrelas, mas atende bem às minhas necessidades e ainda posso dar acesso para quem eu quiser
Não tenho muita certeza de como interpretar esse gráfico
Por um lado, a disponibilidade pode realmente ter piorado por causa da aquisição do GitHub
Por outro, é suspeito que a disponibilidade antes da aquisição apareça como 100,00%; talvez a página de status simplesmente tenha passado a ser atualizada melhor
Sei que houve problemas recentes de disponibilidade no GitHub, mas no gráfico parece que o problema começa em 2020 e não parece piorar dramaticamente
Dá a sensação de que, no fim, é impossível simplesmente deixar grandes repositórios de código aberto em paz
Lembro do SourceForge se deteriorando, e é realmente triste ver algo parecido acontecendo com o GitHub
Aliás, eu li a URL como “inferno do dBus”. Todo mundo já passou por isso pelo menos uma vez
Penso com frequência no que eu faria se administrasse uma empresa
Queria muito ver como seria fazer toda a revisão de código por e-mail
Os repositórios poderiam ficar em um servidor estilo VPS simples, com acesso SSH só para git, com um namespace de branches
for-review/para o código em revisão, e o CI poderia ser um bot esperando esses branches aparecerem para então anexar comentários ou tags à ref indicando aprovação ou falha. Também poderia responder na thread de e-mail com os resultadosA mailing list obviamente poderia ter um visualizador web de arquivo para consultar revisões antigas. Já existem muitas soluções assim, é só HTML
O chat poderia ser em IRC, com um bot arquivando o canal. Muito fácil
O sistema inteiro poderia rodar em servidores muito baratos, exceto pelos runners de CI, que exigiriam hardware mais forte
O GitHub é muito mais engenheirado do que o necessário para tocar projetos de software. Veja o kernel do Linux: usa uma mailing list simples e, ainda assim, dá para argumentar que é o projeto de software mais bem-sucedido de todos os tempos
Só a parte de issues/rastreamento de bugs parece mais assustadora. Tenho medo de começar a improvisar uma solução própria e acabar gastando mais tempo nisso do que no trabalho da empresa. Talvez eu devesse virar uma empresa de software de bug tracking?
Quero dizer: poder ver exatamente a que linha um comentário estava preso, quando essa linha mudou, e navegar para frente e para trás nesse contexto
E-mail talvez baste como protocolo para trocar esses dados, mas não acho que clientes de e-mail sejam uma boa forma de visualizá-los
Talvez também seja necessário um sistema distribuído de revisão de código
Morar no Leste Europeu também tem suas vantagens
Por causa do fuso horário, quase nunca percebo as grandes falhas do GitHub
Também estou satisfeito com a hospedagem gratuita e com o fato de eles oferecerem Actions de forma bem generosa
Depois que instalei o Forgejo no meu servidor caseiro, nunca mais olhei para trás
O único problema é quando vou hospedar apps no DigitalOcean App Platform ou na Vercel, porque eles só se conectam ao GitHub
DigitalOcean App Platformoferece deploy não só a partir do GitHub, mas também do GitLabSó que precisa ser a instância hospedada no gitlab.com, não uma instância self-hosted do GitLab
Se você já implantou seu próprio forge self-hosted, pode usar o gitlab.com como ponte para conectar ao DigitalOcean App Platform. Basta criar uma conta no gitlab.com uma vez e fazer seu forge self-hosted enviar um espelho para lá. Na prática, quase não há necessidade de usar o GitLab de fato
Ainda assim, não faz sentido uma empresa que vende IaaS/PaaS, como a DigitalOcean, não deixar você conectar algo como um Forgejo self-hosted rodando na própria infraestrutura deles
Na verdade, considerando que há muita gente que quer hospedar seu próprio forge, mas pouca gente quer configurar e operar tudo por conta própria, também é estranho que a DigitalOcean não pegue o Forgejo ou alguma alternativa e ofereça uma opção semigerenciada de implantação one-click por algo como 20 dólares por ano, com forte desconto, além de suporte de primeira classe para integração com o App Platform
Eu uso DigitalOcean, mas só para VPS
Não vale a pena ficar preso a esses middle layers de fornecedor; é melhor manter o controle e mirar, sempre que possível, nas camadas mais universais da stack
Troquei para o Gitea há alguns anos, antes mesmo do fork Forgejo, e não me arrependo
Quando o GitHub é necessário, consegui fazer as coisas funcionarem espelhando o repositório para lá. Só é chato manter o código sincronizado
O GitHub está sofrendo porque, com a programação turbinada por IA, o número de commits aumentou 14 vezes no último ano, e esse ritmo ainda está acelerando
O site está tendo dificuldade para acompanhar
O COO do GitHub confirmou isso aqui: https://x.com/kdaigle/status/2040164759836778878
A atividade na plataforma está disparando. Em 2025 houve 1 bilhão de commits, e agora são 275 milhões por semana, então mesmo que o crescimento seguisse só linear, isso já daria um ritmo de 14 bilhões neste ano. Claro que não vai parar no linear
O GitHub Actions passou de 500 milhões de minutos por semana em 2023 para 1 bilhão por semana em 2025, e nesta semana já está em 2,1 bilhões de minutos até agora
Por isso eles estão forçando pesadamente mais CPU, escalando serviços e reforçando as funcionalidades centrais do GitHub