Come migrare da Gitea a Forgejo senza rompere i tuoi repository

Fermi Gitea, installi Forgejo, copi app.ini e la tua directory dei dati, e avvii il servizio nel modo descritto da ogni guida di migrazione. La UI web si avvia. Poi la migrazione del database fallisce, o peggio, Forgejo si rifiuta di avviarsi perché la versione del tuo schema è troppo recente perché possa comprenderla. Sei su Gitea 1.23 o successivo, e il semplice aggiornamento in loco che tutti documentano non si applica più a te.

Forgejo è diventato un hard fork di Gitea all'inizio del 2024, e da allora i due progetti sono divergenti a livello di schema del database. Il modo in cui migri da Gitea a Forgejo ora dipende interamente dalla tua versione di Gitea. Questa guida ti fornisce il percorso esatto per la tua versione, i comandi completi sia per installazioni native che Docker, le soluzioni alternative per Gitea 1.23+ e una checklist di verifica, così puoi migrare senza perdere repository, issue o utenti.

TL;DR

• Il salto di versione è reale. Forgejo v10.0 è stata l'ultima release a supportare un aggiornamento diretto e trasparente da Gitea. Gitea v1.22 è la versione più alta che può percorrere il percorso diretto supportato.
• Su Gitea v1.22 o versioni precedenti: migra prima a Forgejo v10.0.x, poi aggiorna Forgejo v10 alla release attuale (v15). Due passaggi, entrambi supportati.
• Su Gitea v1.23 o versioni successive: non esiste un percorso diretto ufficialmente supportato. Scegli tra un downgrade SQL/schema, script di migrazione della community, migrazione via repository/API, o una migrazione di staging su un nuovo server usando uno di quei metodi. Ognuno comporta un diverso compromesso in termini di perdita di dati.
• Esegui il backup della directory dati e del database prima di toccare qualsiasi cosa. Ogni percorso qui sotto presuppone che tu abbia un backup ripristinabile. I percorsi non supportati lo presuppongono due volte.
• Alcune cose richiedono sempre attenzione dopo la migrazione: pianifica di ricreare o verificare i Personal Access Tokens, ri-registrare i runner di Actions, ed eliminare e ricostruire l'indice di ricerca Bleve. Pianifica questi passaggi indipendentemente dal percorso scelto.
• Migrare non è obbligatorio. Gitea è mantenuto attivamente. La decisione di "restare su Gitea" regge se il rischio della migrazione supera il beneficio per la tua situazione.

Esula da questo ambito: la migrazione da Gogs, GitHub o GitLab a Forgejo, e la configurazione di Forgejo Actions da zero.

Prerequisiti / Cosa ti serve

Prima di eseguire anche un solo comando, conferma di avere un backup completo e ripristinabile di due cose: la directory dati di Gitea (/var/lib/gitea in un'installazione nativa predefinita) e il database. Se il database è SQLite, quel file si trova all'interno della directory dati; se è PostgreSQL o MySQL, esportalo separatamente con pg_dump o mysqldump. Una migrazione senza un backup verificato non è una migrazione, è una scommessa.

Ti servirà anche:

• La tua versione attuale di Gitea. Esegui gitea --version (o docker exec <container> gitea --version). Questo numero determina l'intero percorso da seguire.
• Il tipo del tuo database: SQLite, PostgreSQL o MySQL. Alcune soluzioni alternative sono specifiche per database.
• Accesso root o sudo sul server.
• La consapevolezza che il percorso supportato installa Forgejo v10.0 come passaggio intermedio. Forgejo v10.0 è EOL dal 16 aprile 2025. Lo installi solo per la durata della migrazione e lo aggiorni subito dopo.

Perché il percorso di aggiornamento diretto si è rotto

Nel dicembre 2024 il progetto Forgejo ha pubblicato un dichiarazione di compatibilità che ha tracciato una linea netta: "Le future versioni di Forgejo non supporteranno gli aggiornamenti da istanze Gitea che eseguono la versione v1.23 o superiore." Quella frase è l'intero problema in una riga.

Quando Forgejo si è biforcato da Gitea all'inizio del 2024, le due codebase hanno continuato a divergere e gli schemi dei database si sono progressivamente allontanati. Forgejo ha mantenuto una finestra di compatibilità in modo che gli operatori Gitea esistenti potessero passare, ma quella finestra aveva una fine. Forgejo v10.0, rilasciato il 16 gennaio 2025, è stato "the last version to allow a transparent upgrade from Gitea v1.22 or lower." Qualsiasi versione successiva a v10.0 non leggerà direttamente un database Gitea.

È la tempistica a cogliere di sorpresa le persone. Gitea v1.23 è stato rilasciato alla fine del 2024, e il l'attuale release di Gitea a giugno 2026 è v1.26.4. Se hai mantenuto la tua istanza Gitea ragionevolmente aggiornata, hai già superato lo spartiacque e i tutorial standard non descrivono più la tua situazione.

Il punto della sezione: il percorso diretto supportato si ferma a Gitea v1.22. Tutto ciò che è più recente richiede un passaggio in più.

Trova il tuo percorso di migrazione in base alla versione di Gitea

Esegui gitea --version, trova la tua riga e segui il percorso indicato nella terza colonna. Tutto il resto di questa guida è il dettaglio dietro queste righe.

Le dichiarazioni di compatibilità delle versioni provengono direttamente da annuncio ufficiale di compatibilità di Forgejo: Gitea fino a v1.21 può passare a Forgejo da v7.0 a v10.0, e Gitea v1.22 può passare a Forgejo da v8.0 a v10.0. Entrambi si fermano a v10.0 come ultimo target diretto supportato.

Sotto la questione della versione ci sono tre strategie di migrazione, ed è utile vederle prima delle procedure passo-passo:

• Sul posto, stesso server. Sostituisci il binario o l'immagine del container sulla macchina esistente. Il minimo sforzo quando la tua versione lo supporta; richiede il passaggio intermedio v10.0.
• Staging su server nuovo. Predisponi un nuovo server e usalo come destinazione sicura per il metodo di migrazione adatto alla tua versione di Gitea. Questo protegge la macchina Gitea originale e facilita il rollback, ma non aggira il problema dello schema del database di Gitea 1.23+.
• Migrazione via repository/API. Usa gli strumenti di migrazione di Forgejo per importare i repository dalla vecchia istanza Gitea. La cronologia Git è la parte affidabile; i metadati come issue, PR, etichette, release, dati del wiki e commenti dovrebbero essere trattati come "best-effort" e verificati repository per repository.

Il percorso supportato: Gitea v1.22 o versioni precedenti

Se sei su Gitea v1.22 o versioni precedenti, il documentazione ufficiale di migrazione descrivono un percorso in due passaggi: migra a Forgejo v10.0.x, poi aggiorna Forgejo v10 alla release attuale. Il primo passaggio è una sostituzione diretta perché Forgejo v10.x legge un database Gitea v1.22; il secondo passaggio è un normale aggiornamento di Forgejo.

Ci sono due modi per farlo, a seconda di come Gitea viene eseguito sul tuo server. Scegli quello che corrisponde alla tua configurazione esistente. Se Gitea viene eseguito come servizio di sistema, usa il percorso nativo. Se Gitea viene eseguito in un container, usa il percorso Docker. Forgejo v10.x funge da sostituto diretto per Gitea v1.22.x.

Percorso nativo (systemd)

Esegui prima il backup. Poi installa Forgejo v10.0.x usando il pacchetto della tua distribuzione o il binario di release fissato alla v10.0. Ferma Gitea prima di copiare qualsiasi cosa. Un servizio in esecuzione che scrive nella sua directory dati durante la copia corromperà la copia.

# Stop the running Gitea service before touching its data
systemctl stop gitea

Copia la configurazione e la directory dati nei percorsi di Forgejo, poi correggi la proprietà dei file. Il file di configurazione deve essere leggibile dal gruppo forgejo; i dati devono appartenere all'utente forgejo.

# Copy the existing Gitea config to Forgejo's config path
cp /etc/gitea/app.ini /etc/forgejo/app.ini

# Back up the copied config before rewriting paths
cp /etc/forgejo/app.ini /etc/forgejo/app.ini.bak

# Update old Gitea data paths to Forgejo data paths
sed -i 's#/var/lib/gitea#/var/lib/forgejo#g' /etc/forgejo/app.ini

# Forgejo reads its config as the forgejo group; grant group write
chown root:forgejo /etc/forgejo/app.ini && chmod g+w /etc/forgejo/app.ini

# Copy the data directory and hand ownership to the forgejo user
rsync -aHAX --numeric-ids /var/lib/gitea/ /var/lib/forgejo/
chown -R forgejo:forgejo /var/lib/forgejo

Avvia Forgejo e abilitalo all'avvio.

# Start Forgejo and enable it at boot
systemctl start forgejo && systemctl enable forgejo

Prima di aggiornare da v10.0, svuota le code in modo che nessun lavoro in corso vada perso durante il salto di versione.

# Flush pending queue items before the version upgrade
forgejo manager flush-queues

Ora aggiorna Forgejo v10.0.x alla release attuale sostituendo il binario con la v15 e riavviando il servizio, seguendo la procedura standard di Guida all'aggiornamento di Forgejo. Dopo entrambi i passaggi, esegui il doctor per controllare il database e correggere ciò che può.

# Check everything; write a log you can read if something is wrong
forgejo doctor check --all --log-file /tmp/doctor.log

Leggi /tmp/doctor.log prima di applicare qualsiasi correzione automatica. Usa --fix solo quando l'output del doctor identifica una riparazione specifica che comprendi o quando stai seguendo un percorso ufficiale di risoluzione dei problemi.

Se doctor non riporta errori critici e la UI web elenca i tuoi repository, la prima migrazione è completa.

Percorso Docker / Container

Se Gitea era in esecuzione come container, esegui Forgejo allo stesso modo. Usa l'immagine Forgejo v10.x come sostituto diretto della tua immagine Gitea v1.22.x, puntandola sullo stesso volume dati e database. Verifica prima che la tua versione di Docker sia almeno 20.10.6. Versioni precedenti producono un comportamento indefinito con i container Forgejo.

L'unico dettaglio specifico dei container che inganna le persone: le variabili d'ambiente. Forgejo mantiene il prefisso GITEA_ per compatibilità, ma la documentazione consiglia di passare entrambi i prefissi in modo che la tua configurazione sopravviva a una futura versione di Forgejo che elimina i vecchi nomi.

# docker-compose.yml (excerpt): pass both prefixes for forward compatibility
environment:
  - GITEA__database__DB_TYPE=postgres
  - FORGEJO__database__DB_TYPE=postgres
  # ...repeat the dual-prefix pattern for every config override you pass

Per i container rootless, i dati devono appartenere all'utente 1000 e al gruppo 1000, corrispondenti all'utente di runtime dell'immagine rootless. Dopo che il container si avvia sulla v10.x, esegui lo stesso forgejo doctor check --all dall'interno del container, poi aggiorna il tag dell'immagine alla release attuale v15 e riavvia.

Se sei su Gitea v1.23 o versioni successive

È qui che le guide standard si fermano ed è dove si trova in realtà la maggior parte delle installazioni attuali. Non esiste un percorso diretto ufficialmente supportato per uscire da Gitea v1.23+, quindi ogni opzione qui sotto è o di provenienza community o con perdita di dati. Prima di eseguirne una qualsiasi, fai un backup completo della tua directory dei dati e del tuo database, e conferma di poterlo ripristinare. Questi approcci modificano i dati di produzione; il backup è la tua unica via per annullare.

Le tre opzioni differiscono per rischio e per quanto preservano. Scegli quella il cui compromesso puoi accettare.

Opzione A: Downgrade dello schema SQL / Patch di versione

La soluzione più ristretta consiste nel fare il downgrade della versione dello schema del database in modo che Forgejo v10 lo tratti come un database v1.22.

Nota: non trattare l'aggiornamento della versione come un downgrade completo di per sé. La versione di migrazione registrata e lo schema effettivo devono corrispondere. Su Gitea 1.23.x, testa prima il downgrade completo su una copia e confronta lo schema prima di puntarci Forgejo.

Un maintainer di Forgejo ha descritto l'SQL in Codeberg issue #7638:

-- Downgrade the recorded schema version to the v1.22 baseline (PostgreSQL/MySQL)
UPDATE version SET version=305 WHERE id=1;

Dopo questo, segui il percorso supportato come se fossi su v1.22. L'avvertenza fondamentale: il maintainer ha confermato questo solo per Gitea v1.23.1 nello specifico, non per tutta la v1.23.x. Il numero di versione dello schema è esatto; applicare il valore target sbagliato alla release Gitea sbagliata può lasciare il database in uno stato da cui nessuna migrazione può recuperare. Questo vale per PostgreSQL/MySQL, non è ufficialmente supportato e non è testato come procedura generale.

Consiglio pratico: impostare direttamente version=305 salta la migrazione 304→305, che ha cambiato il modo in cui vengono codificati i segreti TOTP. Codeberg issue #8210 documenta che questo corrompe l'autenticazione a due fattori per gli utenti interessati. La correzione consiste nell'impostare la versione a 304, lasciar eseguire la migrazione, oppure svuotare le righe della tabella two_factor in modo che gli utenti si re-iscrivano. Non saltare questo passaggio se anche un solo account usa TOTP.

Opzione B: Script di downgrade SQL sequenziali (Gitea 1.24–1.25.2)

Per le versioni comprese tra 1.24 e 1.25.2, una singola patch di versione non basta: lo schema è passato attraverso diversi stati intermedi. Gli script della community su xlrl/prepare-gitea-migration-to-forgejo riportano indietro lo schema attraverso le versioni intermedie fino a v1.22, dopo di che segui il percorso supportato. Questi script sono lavoro della community, non una procedura autorevole, e prendono di mira SQLite come caso principale. Eseguili solo su un database di cui hai già fatto il backup.

Opzione C: Migrazione via API repository per repository (Gitea 1.26+ o qualsiasi versione)

Il percorso repository/API preserva i dati Git nel modo più affidabile. A seconda della sorgente, dei permessi e del metodo di migrazione, potrebbero essere disponibili anche metadati opzionali come issue, pull request, etichette, milestone, release, dati del wiki e commenti, ma trattali come un tentativo "best-effort" e verificali repository per repository. Per un archivio di solo codice questo di solito va bene; per un server in cui l'issue tracker è la memoria del team, testa il trasferimento dei metadati prima di impegnarti in questo percorso.

Due strumenti sperimentali tentano migrazioni più complete per 1.23+ ma presentano proprie lacune. pacnpal/gitea2forgejo (GitHub) esegue un dump completo più una sincronizzazione API e richiede una SECRET_KEY corrispondente per trasferire i campi crittografati, ma non sposta i Personal Access Token, gli Actions runner, gli URL di callback dei webhook o il 2FA. nicoverbruggen/gitea-to-forgejo (GitHub) è uno strumento sperimentale basato su Podman che trasferisce utenti, chiavi, organizzazioni, repository, issue, PR, release e mirror, ma non i token 2FA, i dati di runtime di Actions o i manifest dei pacchetti OCI orfani. Considera entrambi sperimentali e verifica il risultato rispetto alla matrice di trasferimento riportata di seguito.

Il punto della sezione: non esiste un percorso diretto ufficialmente supportato per uscire da Gitea 1.23+. Scegli l'opzione il cui compromesso in termini di perdita di dati puoi accettare, e fai un backup prima di iniziare.

Migrare su un server nuovo è più sicuro, ma non aggira lo spartiacque di versione

Un server nuovo è il posto più sicuro per preparare e verificare la migrazione, ma non è un percorso di compatibilità dello schema separato. Se la tua sorgente è Gitea v1.22 o precedente, installa prima Forgejo v10.0.x sulla destinazione, ripristina o copia lì i dati di Gitea, lascia che Forgejo esegua le migrazioni di database supportate, quindi aggiorna quell'istanza Forgejo v10 alla release Forgejo attuale.

Se la tua sorgente è Gitea v1.23 o successivo, non ripristinare il database Gitea direttamente nel Forgejo attuale aspettandoti che si avvii. Hai comunque bisogno di uno degli approcci non supportati per la 1.23+ descritti sopra: un downgrade o un revert SQL graduale, uno strumento di migrazione della community, o una migrazione repo/API. Il server nuovo riduce il rischio di rollback perché la macchina Gitea originale resta intatta; non elimina la necessità di gestire la discrepanza di versione del database.

Questo è il punto in cui Il Forgejo one-click di Cloudzy l'app può aiutarti: usala come istanza di destinazione pulita, poi esegui il metodo di migrazione adatto alla tua versione di Gitea. L'immagine del marketplace di Cloudzy ti offre una destinazione Forgejo pronta sul nostro VPS ad alte prestazioni, così puoi concentrarti sui passaggi di ripristino, verifica e cutover invece che sull'installazione iniziale. Il piano di migrazione dipende comunque dal fatto che tu sia prima o dopo lo spartiacque di Gitea 1.22.

Cosa si trasferisce e cosa devi rifare

Alcuni dei tuoi dati si spostano automaticamente, altri si spostano solo se si verifica una certa condizione, e altri ancora non si spostano mai e devono essere ricreati a mano. Sapere quale sia quale prima di iniziare fa la differenza tra un passaggio pulito e una settimana di utenti confusi.

Quattro elementi colpiscono più duramente perché si rompono silenziosamente o riguardano ogni utente, quindi gestiscili con attenzione: gli utenti dovrebbero ricreare o verificare i loro Personal Access Token, devi registrare di nuovo i tuoi Actions runner contro il nuovo hostname, devi eliminare l'indice di ricerca Bleve affinché Forgejo lo ricostruisca correttamente, e devi riscrivere qualsiasi uses: i riferimenti brevi nei tuoi workflow di Actions in URL completi di GitHub, perché Forgejo e Gitea recuperano le action da mirror separati e un riferimento relativo si risolve nel posto sbagliato.

Consiglio pratico: se esegui Gitea e Forgejo in parallelo durante la migrazione ed entrambi puntano alla stessa istanza Redis, cambia Forgejo su Redis db=1 prima di iniziare. Entrambi usano db=0 come predefinito, e se lo condividono, Gitea consuma gli eventi di migrazione di Forgejo e distrugge la coda di migrazione. (blog.mei-home.net documents this exact failure.)

Il punto della sezione: i Personal Access Tokens, i runner di Actions, le chiavi di deploy per repository e l'indice di ricerca Bleve sono sempre manuali. Pianificali come attività di migrazione, non come ripensamenti.

Verifica che la migrazione sia riuscita

Inizia con il doctor, poi controlla i numeri, poi testa le cose che gli utenti fanno davvero. Il doctor individua i problemi a livello di database; i controlli manuali individuano i problemi di perdita di dati e di accesso che il doctor non può vedere.

1. Esegui forgejo doctor check --all --log-file /tmp/doctor.log, poi leggi il log prima di apportare modifiche. Usa --fix solo per una riparazione specifica che comprendi.
2. Conferma che il numero di repository, i conteggi di issue e PR, e il numero di oggetti LFS con la dimensione totale corrispondano tutti ai numeri precedenti alla migrazione. Una discrepanza qui significa che qualcosa non è stato trasferito.
3. Testa un push e un pull via SSH. Se i client ricevono una discrepanza nella host key, non hai copiato /etc/ssh/ssh_host_* sul nuovo server.
4. Accedi e conferma che il 2FA funzioni per un account che lo utilizza. Se il TOTP è rotto, vedi l'avvertenza sull'Opzione A sopra.
5. Rigenera i Personal Access Tokens, ri-registra i runner di Actions ed esegui un workflow di prova.

Alcuni sintomi post-migrazione hanno cause note. Un favicon o un logo mancante significa che le risorse di branding si trovano ancora in public/assets/img/ invece che in custom/, dove Forgejo ora se le aspetta. Gli errori 404 sulle route dei pacchetti indicano percorsi di storage configurati in modo errato. Le Actions che falliscono con "repository not found" sono il uses: problema dei mirror. Passa a URL completi. Una pagina vuota o un errore 500 dopo il login su un database SQLite significa che sei sotto il minimo, il che la documentazione di aggiornamento ha posto a Forgejo v1.19.3-0.

Quando ha senso restare su Gitea

Migrare è una scelta, non un obbligo. Se sei già oltre lo spartiacque e la complessità della migrazione supera il beneficio di governance o funzionalità per la tua situazione, restare su Gitea è una scelta legittima. Gitea è mantenuto attivamente (più release al mese, attualmente alla v1.26.4), e CommitGo offre opzioni commerciali tra cui Gitea Enterprise, Gitea Cloud e la certificazione SOC 2 Type 2 per i team che ne hanno bisogno.

C'è anche la questione del passaggio intermedio EOL da valutare onestamente. Il percorso diretto supportato richiede di installare brevemente Forgejo v10.0, che è in EOL da aprile 2025. Questo è accettabile come passaggio di migrazione transitorio da cui aggiornarsi immediatamente, ma alcuni operatori obietteranno per motivi di policy. Per loro, la migrazione via repository/API verso una nuova istanza Forgejo può evitare del tutto il passaggio EOL, mentre lo staging su un nuovo server dipende comunque dal metodo di migrazione scelto.

Se il tuo motivo per passare è l'attività di sviluppo, i dati supportano Forgejo come progetto più attivo: un'analisi di honeypot.net ha contato 3,039 commit di Forgejo contro 1,228 commit di Gitea nel periodo da luglio 2024 a maggio 2025, e 232 contributori di Forgejo contro 153 di Gitea nell'anno terminato a maggio 2025. Si tratta di un segnale tra tanti; valutalo rispetto al tuo rischio di migrazione invece di trattarlo come decisivo.

Il punto della sezione: la migrazione non è obbligatoria. La decisione è una preferenza di governance e di attività ponderata rispetto al rischio di migrazione, ed entrambe le scelte sono difendibili.

Scegli il tuo percorso e fai prima un backup

Il tuo percorso di migrazione si riduce a un numero: la tua versione di Gitea. Su v1.22 o precedenti segui il percorso supportato in due passaggi tramite Forgejo v10. Su v1.23 o più recente scegli una soluzione alternativa in base alla perdita di dati che puoi accettare: downgrade SQL/schema, script della community, migrazione via repository/API, o una migrazione di staging su un nuovo server. Qualunque percorso tu scelga, fai prima un backup della tua directory dei dati e del database, esegui forgejo doctor dopo, e conferma che i conteggi di repository, issue e LFS corrispondano a quelli di partenza.

Identifica la tua versione, esegui il backup e segui la riga corrispondente. Il percorso è più complesso di quanto promettessero i vecchi tutorial, ma è ben definito una volta che sai dove ti trovi rispetto allo spartiacque di versione.

Domande frequenti

Posso aggiornare direttamente da Gitea a Forgejo?

Sì, se usi Gitea v1.22 o versioni precedenti: aggiorna direttamente a Forgejo v10.0, poi aggiorna Forgejo v10 alla release attuale. No, se usi Gitea v1.23 o versioni più recenti. Forgejo v10.0 è stata l'ultima release a supportare un aggiornamento diretto trasparente, quindi le versioni più recenti di Gitea richiedono invece una soluzione alternativa.

Quale versione di Gitea è compatibile con Forgejo?

Gitea v1.22 e versioni precedenti hanno un percorso di aggiornamento diretto supportato verso Forgejo (fino a Forgejo v10.0, poi in avanti fino alla versione attuale). Gitea v1.23 e versioni successive non hanno un percorso diretto ufficialmente supportato, perché Forgejo ha smesso di supportare aggiornamenti trasparenti da Gitea v1.23+ a partire dalle release successive a v10.0.

Posso migrare da Gitea 1.26 a Forgejo?

Sì, ma non tramite un aggiornamento diretto supportato. Le tue opzioni sono una migrazione via repository/API, dove la cronologia Git è la parte affidabile e i metadati devono essere testati repository per repository, uno script di migrazione sperimentale, oppure una migrazione di staging su un nuovo server usando uno dei metodi non supportati 1.23+ visti sopra. Non esiste un percorso in loco ufficialmente supportato da Gitea 1.26.

I miei Personal Access Token vengono trasferiti?

Pianifica di ricreare o ruotare i Personal Access Tokens dopo la migrazione. Alcuni percorsi di migrazione non li preservano, e anche quando i token restano presenti, gli utenti dovrebbero verificarne gli ambiti prima di affidarsi di nuovo a essi. Qualsiasi script o integrazione che usi i vecchi token dovrebbe essere testato e aggiornato dopo il passaggio.

I miei workflow Gitea Actions funzionano in Forgejo?

Perlopiù sì, con due correzioni necessarie. Il workflow uses: i riferimenti brevi si rompono perché Forgejo e Gitea recuperano le action da mirror separati. Convertili in URL completi di GitHub (per esempio, uses: https://github.com/sammcj/dotenv-output-action@main). Devi anche registrare di nuovo i tuoi Actions runner, perché i loro token di registrazione sono legati al vecchio hostname.

E la migrazione da Gogs a Forgejo?

Si tratta di una migrazione diversa con un percorso diverso ed esula da questo ambito. Questa guida copre specificamente il passaggio da Gitea a Forgejo; per una sorgente Gogs, consulta la documentazione ufficiale di migrazione di Forgejo per la procedura specifica per Gogs.