GitLab vs GitHub: quale scegliere e quali alternative valutare

Nel confronto GitLab vs GitHub, GitLab è la soluzione più completa per sostituire GitHub; Gitea è invece il primo nome da valutare se vuoi gestire la piattaforma in proprio. Queste 7 alternative a GitHub comprendono servizi gestiti e software self-hosted, ma la scelta dipende da ciò che deve seguire il codice: revisioni, issue, CI/CD e controlli di accesso.

Verificato sulle pagine ufficiali dei produttori il 5 novembre 2026. Il confronto riguarda documentazione e prezzi: non è una prova pratica di migrazione. Per disponibilità si intende che il produttore offre attualmente la registrazione, l'acquisto o l'installazione; non che sia stato creato un account o approvato un contratto.

Le alternative a GitHub a colpo d'occhio

Scegli prima il modello di gestione, poi il fornitore. Un servizio gestito si occupa della piattaforma che ospita il codice. Con il software self-hosted, installazione, backup e ripristino sono sotto il tuo controllo. Un runner CI self-hosted, cioè la macchina che esegue i job di build, non rende di per sé self-hosted un servizio cloud di hosting del codice.

I prezzi indicati sono punti di ingresso, non pacchetti equivalenti. In ogni sezione, i link ai prezzi rimandano alle condizioni del produttore. Una licenza software gratuita non paga il server; un abbonamento per i repository non comprende necessariamente un assistente IA, un sistema di gestione delle issue o capacità di build illimitata.

Prima di cambiare solo per risparmiare, confronta l'alternativa con la pagina dei prezzi attuali di GitHub e con la nostra analisi dei prezzi di GitHub. Metti per iscritto quale esigenza impone il passaggio. Altrimenti, un prezzo inferiore per utente può nascondere costi maggiori di migrazione e manutenzione.

Alternative a GitHub con hosting gestito

L'hosting gestito è la scelta più sensata quando nessuno nel team ha la responsabilità di garantire la disponibilità dell'infrastruttura di sviluppo. Gli sviluppatori possono comunque controllare i permessi dei repository e usare macchine private per le build; il fornitore mantiene l'applicazione di hosting. In questo gruppo, la distinzione principale è fra piattaforme di sviluppo complete e servizi pensati per una comunità o un cloud specifici.

GitLab: la sostituzione più completa

GitLab è una piattaforma di sviluppo che riunisce repository, gestione delle issue, merge request e CI/CD, ossia l'automazione di build, test e distribuzione del software. È il primo candidato da esaminare per un'azienda che vuole mantenere uniti revisione del codice e rilascio dopo aver lasciato GitHub. Un team di prodotto con codice applicativo, backlog e pipeline di rilascio può valutare l'intero ciclo di lavoro in un unico ambiente. Il limite è che resta una migrazione di piattaforma: concetti familiari non rendono identici permessi, automazioni o discussioni pregresse.

Ideale per: Responsabili tecnici che devono sostituire più workflow GitHub collegati.
Punto di forza: Un importatore da GitHub che gestisce i metadati di collaborazione oltre ai dati dei repository.
Prezzi: Free $0; Premium da $29/utente/mese, con fatturazione annuale, nella pagina dei prezzi di GitLab.
Prova gratuita: Il produttore offre una prova dei piani a pagamento oltre al piano Free continuativo.

CI/CD, issue e revisioni: Sono tutte funzioni della piattaforma. Le merge request sono l'equivalente GitLab delle pull request: modifiche proposte che i revisori discutono prima dell'integrazione. GitLab.com Free indica un limite di 5 utenti per gruppo di primo livello e 400 minuti di calcolo al mese. Un gruppo di primo livello è il contenitore organizzativo che raccoglie progetti e membri. Queste quote dell'hosting gestito non vanno applicate a un'installazione amministrata in proprio, né interpretate come capacità di calcolo dedicata.

Assistente IA per il codice: GitLab Duo è l'offerta IA del produttore, con assistenza nelle estensioni IDE e nell'interfaccia GitLab, oltre ad agenti e workflow automatizzati. Un IDE è l'ambiente in cui gli sviluppatori scrivono il codice ed eseguono il debug. Disponibilità e utilizzo dipendono da piano, distribuzione e GitLab Credits; un account hosting Free non garantisce l'accesso gratuito a tutte le funzioni Duo. La documentazione di Duo descrive anche l'hosting dei modelli supportati e un gateway IA, che richiedono una valutazione specifica della distribuzione.

Importazione da GitHub: La documentazione dell'importatore GitHub prevede dati dei repository, issue, pull request, commenti e altri metadati di progetto. Non trasferisce organizzazioni o gruppi GitHub sotto forma di organizzazioni o gruppi. L'importazione degli allegati Markdown è facoltativa: eliminare troppo presto l'origine può quindi interrompere i link storici. La distinzione conta quando una vecchia segnalazione di incidente contiene l'unico screenshot che spiega un guasto in produzione.

GitLab vs GitHub: quando conviene davvero cambiare?

Scegli GitLab quando riunire distribuzione e collaborazione giustifica il cambiamento del modo di lavorare. Resta su GitHub se il problema principale si può risolvere con regole di accesso o controlli di spesa e se il processo di rilascio dipende molto dalle integrazioni esistenti. Migrare perché un assistente non piace, senza verificare se verrà abilitato anche Duo, non risolve la decisione di fondo sulle regole da adottare.

Per il progetto pilota, scegli un repository con una cronologia sufficiente a far emergere i problemi: una revisione chiusa con commenti, un allegato a un'issue e un processo di rilascio attivo. Un repository quasi vuoto dimostra ben poco. Fai esaminare il risultato insieme a uno sviluppatore e a chi approva i rilasci: noteranno problemi diversi.

1. 1

   Prepara la destinazione e limita gli accessi di importazione

   Crea il gruppo di destinazione e verifica che l'utente che importa abbia il ruolo Maintainer o Owner richiesto. Se gestisci GitLab in proprio, abilita GitHub tra le origini di importazione. Usa una connessione OAuth approvata o il metodo con token documentato, limitando gli accessi alla migrazione.

2. 2

   Esegui l'importatore GitHub

   Seleziona Create new, poi New project/repository, Import project e GitHub. Autorizza l'accesso, scegli il repository e controlla il namespace di destinazione e le impostazioni facoltative degli allegati prima di avviare l'operazione.

3. 3

   Verifica separatamente la cronologia della collaborazione

   Confronta branch, tag, issue, commenti di revisione e allegati con l'origine. Controlla con cura identità e accessi. Mantieni GitHub disponibile mentre risolvi le discrepanze: un'importazione completata non dimostra che ogni link storico funzioni.

4. 4

   Ricostruisci il processo di rilascio prima del passaggio definitivo

   Configura pipeline, credenziali e approvazioni di rilascio nella destinazione. Prova un rilascio e un rollback. Poi designa il nuovo repository canonico e rimuovi gli accessi temporanei di migrazione. Il mirroring dei repository di GitLab non sincronizza le successive modifiche alle pull request GitHub.

Bitbucket Cloud: ha senso se il lavoro ruota già intorno a Jira

Bitbucket Cloud è il servizio gestito di Atlassian per repository e revisioni, con Pipelines per build e deployment. È adatto alle aziende in cui gli sviluppatori pianificano già il lavoro in Jira e vogliono collegare l'attività dei repository alle relative attività. Il vantaggio concreto è mantenere ogni modifica legata al compito che l'ha motivata. Il limite riguarda la gestione delle issue: le funzioni native Issues e Wikis di Bitbucket sono state ritirate, quindi non è più una scelta sensata per chi cerca proprio un piccolo tracker autonomo accanto a ogni repository.

Ideale per: Team con un workflow Jira consolidato.
Punto di forza: Attività di repository e pipeline collegate alla gestione del lavoro.
Prezzi: Gratis fino a 5 utenti; Standard da $3.65/utente/mese nella pagina dei prezzi di Bitbucket.
Prova gratuita: Sono disponibili prove di Standard e Premium.

CI/CD, issue e revisioni: Pipelines è integrato; il piano Free indica 50 minuti di build al mese. Sono supportati pull request e revisori, mentre l'applicazione obbligatoria dei controlli di merge va valutata nei piani a pagamento. Per le issue, prevedi Jira o un altro tracker. L'avviso di ritiro di Issues e Wikis di Atlassian conferma la rimozione il 20 agosto 2026.

Assistente IA per il codice: L'offerta Atlassian è Rovo Dev, con assistenza alla programmazione e revisione del codice, ma la composizione dell'offerta sta cambiando. L'avviso sulla transizione di Rovo Dev afferma che il prodotto autonomo si avvia al fine vita, Code Reviewer confluirà negli abbonamenti Jira e Teamwork Collection idonei e la CLI si evolverà in Rovo CLI. La pagina consultata non confermava la data definitiva di fine vita del prodotto autonomo. Chiedi quali diritti d'uso spettano alla tua organizzazione; non pianificare la spesa presumendo che una licenza Bitbucket includa automaticamente un assistente autonomo invariato.

Importazione da GitHub: Usa Create, Repository, poi Import repository con l'URL del repository GitHub e, dove richiesta, l'autenticazione. Atlassian documenta un importatore di repository, non il trasferimento completo di issue, revisioni e regole organizzative GitHub. Gestisci questi elementi come attività separate.

Per un team che usa già Jira, ricondurre le issue GitHub al progetto esistente può essere un riordino ragionevole. Per una piccola azienda che usa soltanto GitHub Issues, può invece significare un nuovo sistema da amministrare. Decidi chi manterrà i collegamenti alle issue e i riferimenti storici prima di considerare il prezzo per utente un risparmio.

Giudizio: Bitbucket merita attenzione per il workflow Atlassian. Se non vuoi Jira, questo vantaggio si riduce sensibilmente.

Azure DevOps Services: pianificazione e distribuzione nell'ecosistema Microsoft

Azure DevOps Services è la suite ospitata di Microsoft che comprende Repos, Boards e Pipelines. È adatta quando attività di lavoro, processi di rilascio e amministrazione organizzativa contano più dell'esperienza sociale di GitHub. Un'azienda che sviluppa applicazioni interne può mantenere nella suite l'attività, la modifica al codice e la discussione sul deployment. Il limite è la copertura: il passaggio ad Azure Repos non conserva tutte le funzioni specifiche di GitHub, comprese tutte quelle che portano il nome Copilot.

Ideale per: Organizzazioni che vogliono riunire pianificazione e infrastruttura di distribuzione.
Punto di forza: Attività in Boards collegate al lavoro su repository e pipeline.
Prezzi: Basic comprende i primi 5 utenti gratis, poi $6/utente aggiuntivo/mese, nella pagina dei prezzi di Azure DevOps.
Prova gratuita: La quota gratuita Basic è continuativa; è distinta dalla prova di Test Plans.

CI/CD, issue e revisioni: Azure Pipelines fornisce CI/CD, Boards tiene traccia delle attività e Repos offre le pull request. La quota gratuita pubblicizzata per le pipeline ospitate comprende un job parallelo con 1,800 minuti al mese. Un job parallelo è la capacità di eseguire un job alla volta, non la garanzia che tutte le build in coda partano insieme. L'attuale documentazione sui job paralleli afferma che il collegamento di un abbonamento Azure valido abilita la quota gratuita per i progetti privati.

Assistente IA per il codice: La revisione del codice di GitHub Copilot per Azure Repos è in anteprima pubblica, con controlli a livello di organizzazione e repository e fatturazione tramite un abbonamento Azure collegato. Può commentare il codice modificato prima della revisione umana. Tuttavia, il passaggio distinto da Azure Boards che chiede a Copilot di implementare un'attività richiede ancora un repository GitHub. La documentazione della revisione in Azure Repos e i requisiti dell'integrazione di programmazione da Boards di Microsoft descrivono integrazioni diverse. Per questa decisione d'acquisto, né «Copilot funziona» né «Copilot non è disponibile» sono affermazioni abbastanza precise.

Importazione da GitHub: Usa il flusso di importazione dei repository con l'URL Git di origine e l'autenticazione richiesta. La guida Microsoft all'importazione Git riguarda l'importazione in un repository di destinazione nuovo o vuoto. Large File Storage, o LFS, conserva i file binari di grandi dimensioni fuori dai normali oggetti Git: i puntatori possono arrivare con il repository, mentre i file sottostanti devono ancora essere trasferiti. Pianifica separatamente la cronologia delle issue e delle pull request GitHub.

Un progetto pilota utile è un servizio esistente con un artefatto di build e un'approvazione del deployment, non soltanto una libreria di codice sorgente. Chiedi al responsabile dei rilasci di seguire una modifica proposta dall'attività in Boards fino al deployment completato. Se il percorso risulta più chiaro di quello attuale, la suite sta apportando un beneficio concreto. Se gli sviluppatori devono ora aggiornare manualmente più tracker, la migrazione ha introdotto un problema di coordinamento.

Codeberg: ottimo per il software libero, inadatto a un prodotto proprietario privato

Codeberg è una forge ospitata senza fini di lucro, cioè un servizio per codice e collaborazione, basata su Forgejo. È una scelta valida per una libreria pubblica o un progetto comunitario i cui collaboratori desiderano una governance orientata al software libero. Il limite è l'idoneità: non è un servizio di hosting commerciale generico per il codice privato di un SaaS. Missione e regole sulle risorse fanno parte della decisione sul prodotto, non sono clausole secondarie da affrontare dopo la migrazione.

Ideale per: Progetti di software libero e open source in linea con la missione dell'organizzazione.
Punto di forza: Hosting orientato alla comunità con una posizione esplicita sull'addestramento dell'IA.
Prezzi: $0 per gli usi idonei, finanziati da donazioni e adesioni facoltative, secondo le FAQ di Codeberg.
Prova gratuita: L'hosting per i progetti idonei è continuativo; non esiste un percorso commerciale dalla prova all'upgrade.

CI/CD, issue e revisioni: Issue e pull request sono disponibili. Woodpecker CI richiede una domanda di accesso e un'approvazione manuale. Forgejo Actions può usare runner self-hosted, con un servizio ospitato limitato in open alpha. La documentazione CI esplicita queste condizioni. «CI disponibile» non significa che ogni nuovo progetto riceva subito una flotta di runner gestiti.

Assistente IA per il codice: Nelle pagine di prodotto consultate non viene pubblicizzato un assistente sviluppato dal fornitore. Codeberg dichiara che non userà i dati dei progetti o degli utenti ospitati per addestrare l'IA generativa e pone restrizioni ai progetti generati in larga parte tramite LLM. La spiegazione pubblicata delle regole distingue inoltre le comunità attive e consolidate e i contributi generati occasionali dai progetti creati o mantenuti in larga misura da agenti. Non ridurre questa posizione all'affermazione che qualunque contributo IA passato renda automaticamente un progetto non idoneo.

Importazione da GitHub: Scegli il menu con il simbolo più, New Migration e GitHub, poi fornisci il token di accesso richiesto e seleziona i metadati da trasferire. La guida alla migrazione di Codeberg comprende issue, etichette, release, milestone e altri metadati supportati. Scegliere l'origine Git generica trasferisce il contenuto del repository senza questi metadati aggiuntivi. Revoca il token di migrazione dopo aver accettato il trasferimento.

Per una dipendenza pubblica mantenuta da volontari, la prima esperienza di un nuovo collaboratore conta quanto l'importazione. Pubblica le nuove istruzioni per contribuire, spiega dove avvengono le revisioni e rendi inequivocabile la sede canonica del progetto. Spostare il repository senza cambiare le abitudini della comunità lascia ai manutentori due luoghi da sorvegliare.

Codeberg esegue la maggior parte dei servizi su hardware proprio a Berlino, ma le sue FAQ descrivono altre sedi e fornitori per alcune attività. Sono informazioni utili sull'infrastruttura, non una promessa contrattuale che ogni copia dei dati resti in Germania. Per un'azienda di software proprietario con requisiti rigorosi sulla localizzazione, valuta una distribuzione ospitata sotto il tuo controllo anziché cercare di ottenere un'eccezione tramite una donazione.

SourceHut: scegli consapevolmente il workflow via email e le regole sull'IA

SourceHut è una suite di sviluppo open source incentrata su Git, mailing list, ticket e build. È adatta ai manutentori che vogliono revisionare le patch via email, con strumenti web di supporto, invece di ricreare l'esperienza delle pull request GitHub. Un progetto che discute già i contributi su una mailing list ha un motivo chiaro per valutarla. I limiti sono il cambiamento del workflow, lo stato di alpha pubblica e le regole sull'IA del servizio ospitato, che escludono molte pratiche di programmazione attuali.

Ideale per: Progetti che preferiscono espressamente la revisione delle patch via email.
Punto di forza: Collaborazione allo sviluppo costruita intorno ai workflow delle mailing list.
Prezzi: Abbonamenti hosting da $4/mese prima delle imposte applicabili; tutti i livelli a pagamento danno accesso agli stessi servizi, secondo la pagina dei prezzi di SourceHut.
Prova gratuita: Per molti servizi il pagamento è attualmente facoltativo durante l'alpha, ma le build richiedono il pagamento; chi contribuisce non deve pagare soltanto per partecipare.

CI/CD, issue e revisioni: La suite comprende builds.sr.ht per la CI, todo.sr.ht per i ticket e la revisione delle patch su mailing list con strumenti web. Una patch è una proposta di modifica al codice inviata per la revisione; i manutentori la discutono e applicano una versione accettata. L'automazione della distribuzione va comunque configurata per il progetto. L'abbonamento non equivale a un sistema di rilascio già pronto.

Assistente IA per il codice: SourceHut pubblicizza esplicitamente l'assenza di funzioni IA. Il suo cambiamento delle regole sull'IA è andato oltre per i nuovi progetti dal 10 settembre 2026: sul servizio ospitato sono vietati i contenuti originali scritti con l'IA generativa o con il suo aiuto e il software che facilita l'IA generativa, secondo l'interpretazione e le eccezioni dichiarate. La spiegazione consente analisi o revisioni private se poi si scrive personalmente il materiale originale. Un team che invia abitualmente codice scritto da assistenti non dovrebbe scegliere questo servizio ospitato.

Importazione da GitHub: Il manuale del servizio Git descrive come importare codice ospitato altrove clonandolo e aggiungendolo a git.sr.ht. Questo fornisce un percorso di trasferimento Git. Non dimostra che le discussioni delle pull request GitHub diventino thread equivalenti su mailing list, né che le issue vengano trasferite automaticamente nel tracker dei ticket. Censisci questi elementi separatamente e decidi cosa deve restare leggibile come archivio.

Prima di trasferire un progetto aziendale, fai seguire a un nuovo arrivato le istruzioni proposte per contribuire. Riesce a inviare una patch, rispondere ai commenti e trovare la versione accettata? Un workflow lineare per un manutentore esperto può comunque richiedere formazione a tutti gli altri. Può valerne la pena, ma deve essere una scelta operativa consapevole.

Il software può anche essere installato in proprio. Tieni distinta questa possibilità dall'idoneità al servizio ospitato di SourceHut: eseguirlo su un'infrastruttura che amministri comporta un modello diverso di distribuzione e responsabilità.

AWS CodeCommit: di nuovo disponibile, ma con una copertura più limitata

AWS CodeCommit è un servizio gestito per repository Git privati, destinato alle organizzazioni che vogliono integrare l'accesso ai repository nel proprio modello operativo AWS. Va incluso nella selezione quando permessi delle identità AWS e confini di rete sono requisiti centrali. L'annuncio di riapertura di AWS afferma esplicitamente che il servizio accetta di nuovo nuovi clienti. Alcuni banner di vecchie pagine AWS dicono ancora il contrario; l'annuncio di riapertura e la cronologia della documentazione attuale superano quell'avviso di chiusura.

Ideale per: Organizzazioni basate su AWS con un requisito specifico sul perimetro dei repository.
Punto di forza: Accesso ai repository integrato con i servizi AWS per identità e infrastruttura.
Prezzi: È disponibile una quota gratuita; l'utilizzo a pagamento costa $1/utente attivo/mese più le eccedenze applicabili, secondo le FAQ sui prezzi di CodeCommit.
Prova gratuita: Il produttore pubblica una quota continuativa, non una prova a tempo dell'intera piattaforma.

CI/CD, issue e revisioni: CodeCommit supporta pull request e collaborazione nelle revisioni. L'automazione di build e distribuzione passa da servizi separati come AWS CodeBuild e AWS CodePipeline. Prevedi un tracker delle issue separato. È una composizione di servizi: confronta workflow e costi risultanti, senza trattare l'hosting dei repository come un abbonamento di sviluppo tutto compreso.

Assistente IA per il codice: AWS offre Amazon Q Developer per l'assistenza alla programmazione. È un'offerta separata: acquistare CodeCommit non aggiunge automaticamente un assistente nativo a ogni repository o revisione. Tieni distinti la scelta del repository e i diritti d'uso dell'assistente.

Importazione da GitHub: AWS documenta una migrazione dei repository Git: recuperare il repository Git esistente, creare la destinazione CodeCommit e trasferire il codice. Non equivale a importare GitHub Issues, conversazioni delle pull request o workflow Actions. Sono sistemi separati da sostituire o conservare.

Il progetto pilota giusto dimostra accesso e distribuzione nella configurazione AWS prevista. L'identità dello sviluppatore designata riesce a recuperare il repository? L'identità di build può accedere soltanto al codice necessario? Il rilascio può procedere con i permessi previsti? Queste domande spiegano perché un team potrebbe scegliere CodeCommit anche se un'altra forge offre un'interfaccia più unificata.

Giudizio: Includilo quando l'integrazione AWS è il motivo del passaggio. Per un fondatore che cerca semplicemente un sostituto familiare di GitHub, valuta prima GitLab o Gitea.

Software self-hosted: Gitea, GitLab e il lavoro di gestione

Il self-hosting è la scelta più adatta quando devi scegliere l'infrastruttura, amministrare l'applicazione e controllarne il ripristino. Ti assegna anche la responsabilità delle interruzioni. La domanda decisiva è se qualcuno sappia ripristinare il servizio quando un disco, un database o un aggiornamento crea problemi, non se l'installazione sembri facile.

Gitea: il primo candidato per il self-hosting

Gitea è una forge open source per repository, issue, pull request e automazione. È il punto di partenza migliore per una piccola organizzazione tecnica che vuole gestire la propria piattaforma del codice senza adottare automaticamente una suite più ampia. Un team che sviluppa strumenti interni può tenere revisioni e attività accanto ai repository, scegliendo dove eseguire il servizio. Il limite è la responsabilità operativa: la licenza gratuita non fornisce backup, monitoraggio, isolamento dei runner o una persona incaricata del ripristino.

Ideale per: Team che vogliono una forge amministrata in proprio e possono assumerne la gestione.
Punto di forza: Repository, issue, pull request e Actions nel prodotto open source.
Prezzi: Open Source costa $0 con licenza MIT; hosting e amministrazione sono esclusi, secondo la pagina dei prezzi di Gitea.
Prova gratuita: L'uso open source è continuativo; il fornitore offre separatamente prove commerciali.

CI/CD, issue e revisioni: Gitea comprende issue e pull request, con Gitea Actions per la CI/CD. La sua documentazione di Actions afferma che è per lo più compatibile con GitHub Actions e usa un programma runner separato. «Per lo più» conta. Un file di workflow familiare facilita la migrazione, ma non dimostra che ogni action, ipotesi sui permessi e integrazione si comporterà allo stesso modo.

Assistente IA per il codice: Nelle pagine del produttore su prodotto e prezzi consultate non viene pubblicizzato un assistente di programmazione proprio. È un'affermazione più circoscritta di un divieto dell'IA. Se usi un assistente separato nell'editor o un bot di revisione, valuta autonomamente accesso ai repository, trattamento dei dati e supporto alle integrazioni.

Importazione da GitHub: La documentazione di migrazione di Gitea descrive il modulo integrato di migrazione da GitHub, che include elementi come issue e pull request quando vengono forniti i dati di account richiesti. Esegui l'importazione su un progetto rappresentativo, poi controlla discussioni e identità. Considera configurazione di Actions e segreti come un'ulteriore prova di accettazione.

Per esempio, un'applicazione interna privata potrebbe avere un workflow di test semplice ma un job di rilascio che presuppone uno specifico provider di identità ospitato. Riutilizzare il job di test non convalida quello di rilascio. Il pilota dovrebbe raggiungere l'ambiente di deployment e dimostrare il ripristino prima che la migrazione venga dichiarata completa.

Gitea vende anche opzioni gestite Cloud ed Enterprise, quindi non è un prodotto esclusivamente self-hosted. Questa raccomandazione riguarda la distribuzione Open Source che amministri tu. Controlli aziendali come il single sign-on SAML, che collega il login al sistema di identità dell'organizzazione, vanno verificati per la specifica edizione, senza presumere che siano presenti nell'installazione gratuita.

Gitea vs GitLab: quanta piattaforma serve davvero?

Scegli Gitea quando una forge mirata copre il lavoro e puoi gestirla. Scegli GitLab Self-Managed quando il workflow GitLab più ampio è il motivo del passaggio e accetti l'amministrazione che richiede. Non scegliere nessuno dei due soltanto perché il software si può scaricare senza una fattura di hosting. Il costo operativo comprende chi indaga su un backup fallito e il tempo che gli sviluppatori perdono durante un'interruzione.

Codeberg è il servizio gestito; Forgejo è il software su cui si basa. Installare Forgejo in proprio è un'opzione diversa dall'aprire un account Codeberg. Anche il software SourceHut si può installare sulla propria infrastruttura. Queste distinzioni evitano un errore comune nella selezione: confondere un servizio ospitato open source con la promessa che il fornitore gestirà la tua installazione privata.

L'offerta Bitbucket amministrata in proprio richiede una verifica separata dell'idoneità. La pagina Hybrid License di Atlassian afferma che l'offerta è destinata ai clienti esistenti di Bitbucket o Bamboo Server/Data Center. Non è un percorso per avviare da zero il self-hosting per un'azienda che parte da GitHub. Allo stesso modo, l'annuncio generale sul ritiro di Data Center non va letto come una dichiarazione indistinta che il prodotto Bitbucket amministrato in proprio stia scomparendo.

Quali alternative a GitHub scegliere per il tuo team?

Se il problema principale è il costo, confronta l'intero ambiente di lavoro prima di migrare. Per una piccola azienda, parti dalle quote gratuite dell'hosting gestito. Includi capacità di build, gestione delle issue, controlli di identità richiesti e accesso agli assistenti. Cambia soltanto se il risparmio o il vantaggio di controllo reggono anche dopo il lavoro necessario a riprodurre il processo di rilascio.

Se il controllo dell'infrastruttura è obbligatorio, parti da Gitea e GitLab Self-Managed. La scelta pende verso GitLab quando la piattaforma più ampia elimina abbastanza strumenti separati da giustificarne l'impegno operativo. Pende verso Gitea quando servono repository, issue, revisioni e una configurazione CI adeguata.

Se la priorità è l'integrazione con l'ecosistema, segui il luogo in cui il lavoro viene già coordinato. Bitbucket si adatta alla pianificazione basata su Jira. Azure DevOps si adatta a un workflow Boards e Pipelines. CodeCommit risponde a un requisito specifico di repository AWS. Adottare un altro ecosistema solo per evitare una fattura può creare più lavoro amministrativo di quanto ne elimini.

Se il progetto è pubblico e guidato dalla comunità, rendi decisiva l'esperienza dei collaboratori. Codeberg è la scelta più chiara per un progetto di software libero che vuole una forge familiare. SourceHut è per i manutentori che scelgono attivamente il suo workflow di revisione delle patch e possono rispettarne le regole sull'IA. Nessuno dei due va scelto soltanto perché un titolo lo definisce gratuito.

Alternative a GitHub Actions: prova prima il job di rilascio

GitLab CI/CD, Bitbucket Pipelines, Azure Pipelines, Gitea Actions, le opzioni CI di Codeberg e le build SourceHut coprono modelli operativi diversi. CodeCommit si collega a uno stack AWS di distribuzione separato. L'unità da migrare è quindi la pipeline funzionante, non il suo file di configurazione.

Censisci i passaggi che dipendono dall'hosting attuale: checkout, cache, accesso ai pacchetti, credenziali di deployment, approvazioni e notifiche. Prova presto il job di rilascio con più vincoli. Se non può essere eseguito in sicurezza nella destinazione, l'importazione riuscita del repository non ha rimosso l'ostacolo. La compatibilità di Gitea può ridurre le riscritture, ma non deve eliminare questa prova.

Alternative a GitHub Copilot: valuta l'assistente separatamente dall'hosting

Cambiare il remote Git non decide quale assistente possa usare uno sviluppatore né dove quell'assistente invii il contesto. GitLab offre Duo; Atlassian offre gli strumenti di sviluppo Rovo in fase di transizione; l'integrazione Microsoft per la revisione in Azure Repos usa GitHub Copilot; AWS offre Amazon Q Developer separatamente. Le pagine di Gitea esaminate non pubblicizzano un equivalente nativo, mentre Codeberg e SourceHut adottano regole che richiedono attenzione oltre alla scelta dell'assistente.

Formula il requisito con precisione: niente addestramento sul codice inviato, niente elaborazione esterna, niente contributi generati oppure nessuna dipendenza da uno specifico fornitore. Sono regole diverse. Una piattaforma può soddisfarne una e non un'altra. Usa la nostra guida ai prezzi di GitHub Copilot per valutare il costo dell'assistente separatamente dall'hosting dei repository.

Residenza dei dati: segui il codice anche fuori dal repository

La posizione del repository è soltanto una parte della scelta sulla localizzazione dei dati. Un runner di build può ricevere codice sorgente, un log può contenere output sensibile e un servizio IA può ricevere frammenti indipendentemente da dove siano conservati gli oggetti Git. Per un responsabile tecnico che deve soddisfare un requisito del cliente, il risultato utile è una mappa di questi trasferimenti e dei contratti che li regolano.

La documentazione Microsoft sulla localizzazione dei dati di Azure DevOps descrive aree geografiche selezionabili, fra cui Europa e Canada, ed eccezioni limitate alla localizzazione dei dati dei clienti. Codeberg descrive le sedi della propria infrastruttura, ma non sostituisce un contratto commerciale di hosting privato. Il self-hosting permette di scegliere dove distribuire il servizio; non impone automaticamente vincoli a un assistente o a un servizio di build esterno.

Chiedi dove risiedano repository, database, backup e log; da dove l'assistenza possa accedervi; e quali sub-responsabili del trattamento ricevano codice. Ripeti poi la stessa verifica per CI e IA. Se il requisito è «nessun codice esce da questo ambiente», applicalo ai collegamenti pertinenti anziché considerare la scelta di una regione di hosting come una risposta completa.

A cosa rinunci lasciando GitHub?

Rinunci a parte della comodità offerta dalla rete di GitHub: i potenziali collaboratori hanno già un account, conoscono l'interfaccia di revisione e possono scoprire un progetto tramite profili e repository familiari. Perdi anche la possibilità di presumere che un componente del marketplace Actions funzioni senza modifiche nella destinazione, con gli stessi permessi e le stesse integrazioni. Far scoprire un progetto open source diventa maggiormente responsabilità tua, anche quando l'alternativa dispone di una comunità competente. Questi costi pesano più per uno strumento pubblico rivolto agli sviluppatori che cerca collaboratori che per un'applicazione interna privata. Un mirror pubblico può mantenere la visibilità, ma richiede istruzioni inequivocabili per contribuire e una sede canonica chiara; altrimenti crei issue e revisioni duplicate che i manutentori devono sorvegliare.

Come sono state selezionate le piattaforme

La selezione privilegia elementi completi per decidere rispetto alle classifiche basate sul numero di funzioni. Per ogni opzione sono stati verificati disponibilità attuale, modello di hosting, CI/CD, issue e revisioni, offerta IA dichiarata dal produttore, percorso di importazione da GitHub e prezzo iniziale pubblicato. GitLab, Bitbucket, Azure DevOps e Gitea mostravano percorsi di registrazione, acquisto, prova o download; Codeberg e SourceHut mostravano percorsi di registrazione; AWS confermava esplicitamente la riapertura delle iscrizioni.

Il confronto è stato verificato il 5 novembre 2026 sulle pagine ufficiali di prodotto, prezzi e documentazione. Non sono state eseguite misurazioni delle prestazioni, prove dei tempi di risposta dell'assistenza o migrazioni di prova. Le raccomandazioni sono valutazioni dell'adeguatezza dei workflow basate su queste evidenze. Una descrizione favorevole non supera le regole di idoneità di un progetto né la necessità di provare il suo processo reale di rilascio.

Quando escludere un'alternativa

Evita Codeberg per un'azienda che sviluppa un prodotto proprietario privato. La sua missione è un motivo per sceglierlo per il software libero e per escluderlo dal normale hosting commerciale privato. Le donazioni facoltative non comprano regole d'uso diverse.

Evita SourceHut ospitato se il normale processo di contribuzione dipende da codice generato o se il prodotto facilita l'IA generativa. Le regole attuali pongono un problema sostanziale di compatibilità, non un'impostazione facoltativa dell'assistente. Evitalo anche se i collaboratori hanno bisogno di un'esperienza di revisione simile a GitHub e nessuno ha previsto risorse per la formazione sul workflow.

Non considerare Bitbucket Hybrid un percorso di acquisto self-hosted per nuovi clienti. La pagina sui requisiti parla esplicitamente di clienti esistenti. Valuta l'offerta Cloud presente in questo elenco, oppure scegli software che puoi distribuire in proprio.

Evita CodeCommit come sostituto tutto compreso predefinito. Può essere il servizio AWS giusto per i repository, ma il workflow circostante per issue e distribuzione deve ancora essere progettato. La vecchia chiusura delle iscrizioni non è più un motivo valido per scartarlo.

Evita qualsiasi migrazione dimostrata soltanto da un clone riuscito. Se i revisori non riescono a ritrovare le decisioni alla base del codice, o se la destinazione non riesce a rilasciarlo, il trasferimento della piattaforma è incompleto.

Checklist per accettare la migrazione

Valuta la migrazione per livelli separati, così che un trasferimento pulito del repository non nasconda un workflow non funzionante. La checklist seguente è un criterio di valutazione, non l'affermazione che ogni importatore trasferisca ogni livello.

1. 1

   Verifica la completezza del repository

   Confronta branch e tag previsti, esamina commit rappresentativi e conferma che i file di grandi dimensioni siano recuperabili. Mantieni un backup indipendente e conserva l'origine fino all'accettazione della migrazione.

2. 2

   Verifica che le decisioni restino consultabili

   Esamina un'issue, una revisione chiusa, un allegato e una nota di rilascio. Decidi quale cronologia mancante verrà importata, archiviata o collegata. Assegna a qualcuno la responsabilità di risolvere i riferimenti interrotti.

3. 3

   Verifica che la destinazione possa rilasciare il software

   Configura con cura credenziali, accesso agli artefatti e approvazioni del deployment. Esegui il processo di rilascio verso una destinazione sicura, poi prova il ripristino. Revoca le credenziali temporanee di importazione dopo l'accettazione.

4. 4

   Verifica accessi e responsabilità del passaggio definitivo

   Controlla gli accessi di uno sviluppatore, un revisore, un'identità di build e un utente in uscita. Pianifica la sincronizzazione finale, comunica dove inviare i nuovi contributi e nomina la persona autorizzata ad annullare il passaggio.

La prossima sessione di lavoro dovrebbe produrre il risultato di un pilota, non un elenco più lungo di candidati: scegli la destinazione che soddisfa il vincolo obbligatorio, migra un repository rappresentativo e fai accettare il workflow al responsabile dei rilasci. Estendi la migrazione soltanto dopo aver ottenuto questa prova.

Domande frequenti

Qual è la migliore alternativa a GitHub?

GitLab è il sostituto più completo se vuoi riunire repository, issue, revisioni e CI/CD. Gitea è la prima opzione self-hosted da valutare quando una forge mirata copre il lavoro e puoi gestirla. La dipendenza da Jira, le regole della comunità o un perimetro AWS possono cambiare la raccomandazione.

È meglio TFS o Git?

Sono strumenti di tipo diverso. Team Foundation Server, predecessore di Azure DevOps Server, è una piattaforma di sviluppo. Git è un sistema distribuito di controllo delle versioni. Se intendi Git rispetto a Team Foundation Version Control, la panoramica Microsoft di TFVC spiega l'alternativa centralizzata. Non devi abbandonare Git per cambiare il servizio che ospita i repository.

La NASA usa Git?

Sì. La NASA descrive l'uso di GitHub per pubblicare software open source nella sua panoramica sullo sviluppo open source. Questo documenta un uso reale dei repository Git, non una regola universale per ogni sistema della NASA.

GitHub è ancora open source?

La piattaforma ospitata di GitHub è proprietaria. Git, lo strumento di controllo delle versioni sottostante, è open source e GitHub ospita molti progetti open source. Sono cose diverse: scegliere un progetto open source non significa scegliere una piattaforma di hosting open source.

Perché alcune persone boicottano GitHub?

Le ragioni variano e comprendono obiezioni all'hosting proprietario, alla dipendenza dal fornitore e all'uso dell'IA. Codeberg e SourceHut pubblicano posizioni esplicite su IA e governance del software, discusse sopra. Per la tua organizzazione, trasforma la preoccupazione in un requisito verificabile anziché presumere che tutte le alternative adottino le stesse regole.

Come spiegare GitHub a chi parte da zero?

GitHub è uno spazio di lavoro condiviso per il codice. Conserva la cronologia delle modifiche, permette di proporre e revisionare aggiornamenti e supporta la gestione delle issue e l'automazione. Le alternative differiscono per quanta parte di questo ambiente offrono e per chi lo gestisce.

Usare GitHub comporta rischi?

La domanda utile è quale rischio devi controllare: accesso agli account, credenziali esposte, permessi dei repository, automazioni di terze parti o trasferimenti di dati. Cambiare fornitore non elimina queste responsabilità. Con il self-hosting, anche patch, backup e ripristino diventano responsabilità tua.

GitHub è posseduto al 100% da Microsoft?

Sì. Microsoft ha completato l'acquisizione di GitHub nel 2018, come riporta il suo annuncio di acquisizione. Passare ad Azure DevOps cambia la piattaforma mantenendo Microsoft come fornitore.

Il governo degli Stati Uniti usa GitHub?

Sì. L'uso pubblicato dalla NASA è un esempio federale documentato. Questo non dimostra che GitHub, o un'alternativa, sia approvato per ogni progetto governativo o categoria di informazioni.

Prima di cambiare lo stack di sviluppo, scarica la checklist di audit dei workflow aziendali con l'IA per mappare ciò che il nuovo workflow deve conservare.