Shopping cart

Subtotal $0.00

View cartCheckout

Building better devs

TnewsTnews
  • Home
  • Notícias
  • GitHub Vai Usar Seu Código para Treinar IA: Hora de Migrar para o Codeberg
Notícias

GitHub Vai Usar Seu Código para Treinar IA: Hora de Migrar para o Codeberg

Email : 70

Hoje, 26 de março de 2026, o GitHub publicou uma atualização silenciosa na sua política de uso de dados: a partir de 24 de abril, as interações com o Copilot — incluindo código, nomes de arquivo, estrutura de repositório e histórico de chat — serão usadas para treinar modelos de IA por padrão. Opt-out. Você precisa desativar manualmente.

É a gota d’água pra muita gente.

O Hacker News explodiu com a notícia. No mesmo dia, o artigo “Moving from GitHub to Codeberg, for lazy people” chegou ao topo do ranking com 485 pontos — um sinal claro de que essa discussão passou do nível teórico para o prático. Devs estão mesmo saindo.

Se você ainda não pensou nisso, é um bom momento para pensar.


O que o GitHub anunciou exatamente

Pra ser justo, o GitHub foi razoavelmente transparente sobre o que coleta. Segundo a atualização de política, os dados coletados para treino incluem:

  • Entradas e saídas do Copilot (os prompts e as respostas)
  • Trechos de código submetidos ao contexto do modelo
  • Nomes de arquivos e estrutura de repositório
  • Padrões de navegação dentro do IDE
  • Histórico de chat e feedback dado às sugestões

O ponto que gerou mais raiva: repositórios privados. O GitHub diz que não usa o código em repouso de repos privados — mas as interações do Copilot dentro de repos privados estão incluídas na coleta. Se você tem um projeto confidencial e usa o Copilot Pro ou Free, suas interações podem ir para o treinamento.

Copilot Business e Enterprise ficam de fora. Mas esses planos custam entre $19 e $39 por usuário por mês. Ou seja: quem paga mais fica protegido. Quem usa o plano gratuito ou básico financia o modelo com seus dados.

Na thread da comunidade do GitHub, a proporção foi 59 reações negativas para 3 positivas. Não é exatamente uma recepção calorosa.


Por que o Codeberg ganhou relevância agora

O Codeberg não é novidade. A plataforma existe desde 2019, gerenciada pela Codeberg e.V., uma organização sem fins lucrativos sediada em Berlim. Mas por muito tempo ficou como a “opção ética que ninguém usa de verdade”.

Isso está mudando.

Com quase 300 mil usuários e 465 mil projetos, o Codeberg cresceu bastante nos últimos dois anos. E o motivo não é técnico — é político. Tem muito dev que simplesmente não quer que o Microsoft Azure leia seu código pra treinar um modelo que vai ser vendido de volta pra ele.

O Codeberg roda em cima do Forgejo, um fork do Gitea criado em 2022. O Forgejo nasceu depois que a Gitea Inc. mudou de governança e começou a aceitar investimento corporativo. Um grupo de contribuidores resolveu forkar e criar uma alternativa com governança democrática e 100% free software. Hoje o Forgejo tem 232 contribuidores ativos, contra 153 do Gitea — e mantém um ritmo de desenvolvimento mais acelerado.

A interface do Forgejo é familiar pra quem já usou GitHub ou GitLab. Não tem aquele choque de “onde está tudo?”. E migrar não é mais a aventura complicada que foi no passado.


Migrando do GitHub pro Codeberg: na prática

A boa notícia: o Codeberg tem importação nativa do GitHub. Você entra na sua conta, clica em “Migrate Repository” e cola a URL do repo. Ele importa:

  • Todo o histórico de commits
  • Issues (com os números originais preservados)
  • Labels
  • Informações de autoria

O que não vem automaticamente:

  • Pull requests (issues viram issues, mas PRs precisam de tratamento especial)
  • GitHub Actions (precisa ser adaptado)
  • Integrações de terceiros (webhooks, apps do marketplace)

Pra maioria dos projetos pessoais ou de código aberto, a migração leva menos de 10 minutos.

Passo 1: Criar a conta e importar

Crie sua conta em codeberg.org. Depois, clique em + → “New Migration” → “GitHub”. Você vai precisar de um token do GitHub com permissão de leitura pra que o Codeberg acesse repos privados durante a importação.

Settings → Developer settings → Personal access tokens → Generate new token
Scopes necessários: repo, read:org (se tiver orgs)

Passo 2: Atualizar o remote local

Depois de importar, atualize o remote nos seus repositórios locais:

# Ver remote atual
git remote -v

# Substituir pelo novo remote no Codeberg
git remote set-url origin https://codeberg.org/seu-usuario/seu-repo.git

# Confirmar
git remote -v

Passo 3: Migrar CI/CD

Esse é o ponto mais trabalhoso. O Codeberg usa Forgejo Actions, que tem sintaxe praticamente idêntica ao GitHub Actions. A diferença principal: referências a actions externas precisam de URL completa.

Onde você tinha:

uses: dtolnay/rust-toolchain@stable

Vira:

uses: https://github.com/dtolnay/rust-toolchain@stable

Pequena mudança, grande impacto. A maioria das actions populares funciona dessa forma. O que não funciona são os runners da Microsoft — especialmente os macOS runners, que o GitHub oferece gratuitamente. Se seu projeto tem testes em macOS, você vai precisar ou cross-compilar, ou hospedar seu próprio runner.

Para projetos puramente Linux, a migração é quase transparente.

Passo 4: Hosting de site estático

Se você usa GitHub Pages, o equivalente no Codeberg é o Codeberg Pages. O modelo é o mesmo: um branch ou pasta específica serve o conteúdo estático. A configuração é basicamente igual.

Diferença importante: o Codeberg Pages não tem SLA formal de uptime. Na prática, funciona bem — mas não espere o mesmo suporte corporativo de uma plataforma da Microsoft.

Passo 5: Arquivar o repo antigo

Não delete o repo do GitHub. Archive. Vá em Settings → Danger Zone → Archive this repository. Isso mantém o repo visível e clonável, mas desativa issues e PRs. Atualize o README com um link pro novo endereço.

> ⚠️ Este repositório foi movido para o Codeberg:
> https://codeberg.org/seu-usuario/seu-repo

O que você perde (sendo honesto)

Não vou vender ilusão. Sair do GitHub tem custo real.

GitHub tem 180 milhões de desenvolvedores. Codeberg tem 300 mil. Se o seu projeto depende de visibilidade, estrelas, forks e colaboradores externos, essa diferença importa. Muito.

O marketplace de integrações do GitHub é incomparável. Dependabot, GitHub Actions runners gerenciados, Codespaces, Advanced Security, integração com NPM, Pages com CDN global — é uma plataforma madura com anos de investimento. O Codeberg é funcional, mas não tem nem 10% disso.

CI/CD gratuito no GitHub é generoso. 2.000 minutos por mês em projetos privados, ilimitado em públicos. O Codeberg não oferece runners gerenciados ainda — você precisa hospedar os seus ou usar alternativas como o Woodpecker CI.

Pull Requests não migram. Histórico de PRs fica no GitHub. Se você tem anos de code review documentado lá, ele não vem junto.

A migração faz sentido dependendo do seu perfil:

PerfilVale migrar?
Projetos pessoais / hobby✅ Fácil e faz sentido
Open source pequeno/médio✅ Com algum esforço
Time pequeno, projetos privados⚠️ Avalie o custo de CI/CD
Open source grande com comunidade ativa❌ Perda de visibilidade é real
Empresa dependente do GitHub Enterprise❌ Custo de migração proibitivo

Forgejo como alternativa self-hosted

Se você não quer depender de nenhum serviço externo, o Forgejo resolve o problema de uma vez. Você hospeda tudo no seu servidor, seus dados ficam onde você colocar.

A instalação é simples:

# Com Docker
docker run -d \
  --name forgejo \
  -e USER_UID=1000 \
  -e USER_GID=1000 \
  -p 3000:3000 \
  -p 22:22 \
  -v /opt/forgejo:/data \
  codeberg.org/forgejo/forgejo:latest

Em minutos você tem uma instância rodando. Com um VPS de $6/mês você hospeda facilmente dezenas de repositórios pessoais.

O Forgejo tem:

  • Interface web completa (idêntica ao Gitea)
  • Actions compatível com GitHub Actions
  • Webhook support
  • OAuth (pode usar seu GitHub como provider de login)
  • API compatível com Gitea (e parcialmente com GitHub)
  • Suporte a mirrors — você pode espelhar seus repos do GitHub automaticamente

A grande vantagem: seus dados, seu servidor, suas regras. Nenhum modelo da Microsoft vai ver seu código a não ser que você deixe.


O contexto maior: onde o GitHub errou

O problema não é só a coleta de dados de hoje. É o padrão que o GitHub estabeleceu ao longo dos últimos 4 anos.

Quando o Copilot foi lançado em 2021, a maior polêmica foi que ele teria sido treinado em código open source sem a permissão explícita dos autores. A questão legal ainda não foi totalmente resolvida. Vários projetos, incluindo o Linux kernel e partes do GCC, levantaram objeções.

Depois veio a política de uso de dados de 2023, que também gerou reação. Depois os termos de serviço de 2024. Agora isso.

Cada vez que o GitHub mexe nos termos, a comunidade reage e depois esquece. Mas a memória institucional acumula. Em setembro de 2025, o pedido mais votado no fórum da comunidade do GitHub era “desabilite o Copilot completamente na nossa organização”. Não era um bug report. Era um pedido de remoção de feature.

Quando o produto mais comentado da sua plataforma é o que os usuários mais querem desligar, alguma coisa está errada.


Como desativar a coleta de dados no GitHub (se você ainda vai ficar)

Se decidir continuar no GitHub, pelo menos desative a coleta. O processo é manual e precisa ser feito conta a conta — não existe configuração global por organização nos planos básicos.

Para conta pessoal:

  1. Acesse github.com/settings/copilot
  2. Role até “Policies”
  3. Desative “Allow GitHub to use my data to improve GitHub Copilot”

Para organizações (plano Business/Enterprise):

  1. Vá em github.com/organizations/SEU-ORG/settings/copilot/policies
  2. Em “Suggestions matching public code”, configure conforme necessário
  3. Em “Data collected”, desative o treinamento de modelos

O detalhe irônico: pra desativar você precisa estar logado no GitHub, navegar pela interface dele, e confiar que o opt-out é respeitado. Não tem auditoria pública. Não tem confirmação técnica. Você clica e torce.

Pra quem prefere garantias por design em vez de promessas de interface — o Codeberg não coleta dados de treinamento de IA porque não tem um produto de IA pra treinar.


Outras alternativas além do Codeberg

O Codeberg é a opção mais ética e simples, mas não é a única. Dependendo do seu contexto, outras plataformas podem fazer mais sentido.

GitLab

O GitLab é a alternativa mais completa ao GitHub em termos de features. Tem CI/CD nativo robusto, container registry, security scanning, gerenciamento de issues avançado e uma versão self-hosted bastante usada por empresas.

O CERN, a NASA e o projeto GNOME hospedam código no GitLab. A versão Community Edition é open source e pode ser instalada em qualquer servidor.

A desvantagem: o GitLab é pesado. Pra um VPS pequeno, a instalação self-hosted pode ser overkill. E a empresa por trás também é comercial — não tem a mesma filosofia sem fins lucrativos do Codeberg.

Gitea

Antes do Forgejo, o Gitea era a opção mais popular pra self-hosting leve. Ainda é muito usado. Se você já tem uma instância rodando, faz sentido manter — mas novos projetos provavelmente se beneficiam mais do Forgejo, que tem governança mais saudável.

SourceHut (sr.ht)

O SourceHut é a mais radical das alternativas. Interface minimalista ao extremo, funcionamento baseado em email (sem botão de pull request — você manda um patch por email), filosofia purista de free software.

Não é pra todo mundo. Mas se você valoriza simplicidade e controle acima de tudo, é fascinante. Drew DeVault, o criador, é uma das vozes mais consistentes sobre soberania de software na comunidade open source.


Não precisa ser uma migração total

Pra maioria das pessoas, a resposta prática não é “delete o GitHub amanhã”. É diversificação.

Coloca seus projetos pessoais no Codeberg. Mantenha os repos de trabalho onde estão. Espelhe os projetos open source importantes. Aprenda a usar o Forgejo Actions antes de precisar. Reduza sua dependência gradualmente.

O Codeberg suporta mirrors automáticos — você pode manter seus repos sincronizados com o GitHub por um tempo enquanto a migração acontece. Qualquer push no Codeberg pode ser espelhado de volta pro GitHub (ou vice-versa), o que elimina o medo de “e se eu precisar voltar”.

# No Codeberg: Settings → Mirror Settings
# Adicionar um push mirror apontando pro GitHub
# O Codeberg vai manter os dois em sincronia automaticamente

Dessa forma você não perde nada durante a transição. Testa o Codeberg por 30 dias sem abandonar o GitHub. Se funcionar, arquiva o repo antigo. Se não funcionar, você ainda tem tudo lá.

O importante é parar de assumir que o GitHub é a única opção — ou pior, que é neutro. Toda plataforma tem dono, tem interesses e tem incentivos. Entender isso já é metade do caminho.

A outra metade é configurar o git remote set-url.


Fonte de inspiração: Moving from GitHub to Codeberg, for lazy people — #1 Hacker News em 26/03/2026

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts