GitCode

Apri Configurazione, in alto a destra accanto al selettore della lingua. Il pannello mostra quattro passi e dice da sé quali sono già fatti; lo stato viene riletto ogni volta che il pannello si apre.

Installare git e GitHub CLI

Se git o gh risultano da fare hai due strade:

• Installa con PowerShell: si apre una finestra col comando winget già scritto, premi Invio e aspetti;
• Vai al sito: apre la pagina ufficiale di scaricamento, per chi preferisce installare a mano.

Finita l'installazione premi Ricontrolla: il PATH di Windows viene riletto dal registro e l'attrezzo si trova subito, senza riavviare niente.

Collegare l'account GitHub

Premi Collega il mio account GitHub: si apre un terminale che fa quattro domande in inglese, e accanto a ciascuna il pannello scrive la risposta da dare:

• What account do you want to log into? → GitHub.com
• What is your preferred protocol? → HTTPS
• Authenticate Git with your GitHub credentials? → Y
• How would you like to authenticate? → Login with a web browser

Compare un codice: lo ricopi nel browser e autorizzi. Il token lo tiene gh nel portachiavi di Windows: GitCode non chiede e non salva nessuna password.

Nome ed email dei commit

Scrivi nome ed email e premi Salva: finiscono dentro ogni commit. Premi Ricontrolla: se i quattro passi sono verdi, hai finito.

Scegli la cartella di lavoro con Cambia cartella in alto: il programma lavora sempre e solo su quella; Apri cartella la apre in Esplora file. Lo stato della cartella si rilegge da solo, ogni volta che la finestra torna in primo piano e dopo ogni operazione.

Il prossimo passo

Sotto la cartella una riga grande dice cosa fare adesso, e sotto di lei stanno i tre pulsanti dell'operatività col numero d'ordine:

• 1 · A pagamento, facoltativo;
• 2 · Prepara per il sito, solo con la pubblicazione su sito personale accesa (senza, Pubblica è il 2);
• 3 · Pubblica.

Il prossimo da premere è evidenziato, gli altri attenuati. Manca il repository → pulsante 1 «Crea il repository su GitHub»; sito.json e README non ancora compilati → Prepara per il sito; modifiche, commit non inviati o una release che manca → Pubblica; altrimenti la riga dice «Tutto pubblicato, niente da fare».

La striscia colorata sotto dice se la cartella è un repository, su che ramo sei, quante modifiche non hai ancora salvato e a quale repository GitHub punta.

Pubblica

Quando hai finito di lavorare premi Pubblica: scrivi una riga su cosa hai cambiato, o tieni quella già compilata con data e ora, e il programma fa add -A, commit e push. Se il ramo non ha ancora un upstream lo crea.

Se la cartella non ha un origin il commit resta locale, e il messaggio lo dice: per crearlo c'è il pulsante 1.

La release

Dopo un push riuscito, se nella cartella c'è qualcosa da compilare, GitCode chiede se pubblicare anche una release con l'installer allegato. Col sì:

• propone la patch successiva con le note già scritte dai commit;
• alza la versione in tauri.conf.json, package.json e Cargo.toml (in un workspace Cargo da [workspace.package] del Cargo.toml radice, e anche dalla riga #define AppVersion di uno script Inno Setup se c'è);
• compila con npm run tauri build, oppure con cargo build --release e Inno Setup sullo script .iss per un progetto Rust; se la compilazione fallisce per un percorso che non esiste più (cache vecchia, cartella spostata) pulisce target con cargo clean e riprova una volta, scrivendolo nel registro;
• cerca l'installer in tutta la cartella del progetto (fuori da node_modules e .git): il setup .exe o .msi con la versione appena compilata nel nome, il più recente se ce n'è più d'uno, e scrive nel registro dove l'ha trovato; se nessun file porta quella versione si ferma elencando i setup visti;
• con la Pubblicazione su sito personale accesa, prima di compilare verifica che il giro automatico delle schermate sia davvero nel codice del progetto e, se manca, lo inserisce da solo (allora ricompila comunque: un giro aggiunto dopo la build non sarebbe dentro l'eseguibile);
• a compilazione riuscita avvia l'eseguibile appena compilato e rifà tutte le schermate: le nuove prendono il posto delle vecchie in images/screenshots/ rinumerate da 01.png, la copertina scelta a mano resta la tua e se /uploads/1788628459462-cover.png manca la fa con la prima schermata nuova, e l'elenco in sito.json e le immagini nel README si aggiornano con i file appena scattati;
• solo dopo fa commit, tag, push e gh release create: immagini, sito.json, README e installer escono in una release sola.

Nella cartella di uscita resta soltanto l'installer nuovo. Se manca origin, se gh non è autenticato o se il tag esiste già, si ferma prima di toccare qualsiasi cosa. Se si ferma dopo, prima del commit — compilazione fallita, installer non trovato — la versione scritta nei file torna quella di prima e alla pubblicazione successiva viene proposto lo stesso numero.

Se apri una cartella già pubblicata a cui manca la release, GitCode lo scrive nel registro e non fa altro: niente si compila né si pubblica da solo. La pubblichi tu da Pubblica, che te la propone anche quando non c'è niente da salvare.

La copia pubblica delle release

Il codice resta nei repository privati del tuo account. I download stanno su un secondo account GitHub, pubblico, usato solo come vetrina: un repository per software, con sole release. Il nome di quell'account lo scrivi tu in fondo alla Configurazione, nel campo Nome dell'account pubblico.

Su quell'account si crea un token fine-grained da Settings → Developer settings → Personal access tokens → Fine-grained tokens → Generate new token:

• Repository access: All repositories;
• Permissions: Contents e Administration in Read and write;
• scadenza: nessuna.

Il token si incolla nel campo Token dell'account pubblico, accanto al nome. Nome e token restano salvati solo nelle preferenze di questo PC: mai nel codice, mai nell'installer.

A ogni Pubblica, e da Prepara per il sito, prima ancora di guardare se c'è qualcosa da salvare, GitCode controlla che la copia pubblica sia completa e fa quello che manca:

• crea il repository pubblico ACCOUNT/NOME con sole release;
• scrive il secret RELEASE_TOKEN nel repository privato;
• aggiunge il workflow .github/workflows/mirror-release.yml, che copia ogni release nuova con l'installer rinominato NOME-setup.exe;
• copia subito sul pubblico l'ultima release che il privato ha già, con l'installer rinominato allo stesso modo.

Il link fisso da mettere sul sito è https://github.com/ACCOUNT/NOME/releases/latest/download/NOME-setup.exe e punta sempre all'ultima versione. Un software già configurato a mano si riconosce e non si tocca.

Vale anche per i software pubblicati prima che la copia pubblica esistesse: basta premere Pubblica una volta. Se l'unica cosa che mancava era il workflow, Pubblica fa commit e push di quello soltanto, senza alzare la versione né creare una release; se ci sono anche modifiche vere, il giro è quello di sempre. Ogni passo sta nel registro. Se il nome o il token mancano, la copia pubblica non parte, la release resta nel solo repository privato e il registro lo dice.

Il modulo aggiornamenti

Ogni software pubblicato col pulsante 1 riceve, se non lo ha già, il modulo aggiornamenti, con dentro già scritti il nome dell'account pubblico e quello del repository:

• per Rust/Tauri un modulo Rust collegato al programma e una barra in fondo alla finestra, in cinque lingue;
• per Python un aggiornamenti.py con barra e popup per tkinter e le funzioni per qualunque altra interfaccia;
• per gli altri linguaggi il registro dice che il modulo non è disponibile.

All'avvio del software, e a ogni «Cerca aggiornamenti», il modulo legge l'ultima release su GitHub e mostra sempre versione installata, ultima versione disponibile, data e ora di pubblicazione nell'ora locale ed esito dell'ultimo controllo. Se l'ultima è più nuova compare un popup con un pulsante che apre il link del setup, e la riga lampeggia finché non ci clicchi sopra o premi «Cerca aggiornamenti»; poi torna normale fino alla release successiva. Nessun download automatico: se la rete manca il programma parte lo stesso e scrive «controllo non riuscito».

Dopo ogni pulsante 1, chiuso il riepilogo, se su GitHub ci sono commit dopo l'ultima release e c'è qualcosa da compilare GitCode propone la release con la patch alzata, ogni volta finché non la si fa; il registro scrive «release proposta» o «release rifiutata dall'utente». Senza release nuova il modulo non arriva sulla copia pubblica.

GitCode usa lo stesso modulo su di sé: la riga sotto il nome, in alto a sinistra, dice la versione installata, l'ultima pubblicata con data e ora e l'esito del controllo, e «Cerca aggiornamenti» ti dice se sei aggiornato.

Non c'è una sequenza obbligata: ogni pulsante funziona da solo.

1 · Crea il repository su GitHub

Prende la cartella e la mette online, privata o pubblica. Prima riconosce il linguaggio: dai metadati .progetto.json, altrimenti dal contenuto della cartella, altrimenti te lo chiede. Il linguaggio trovato compare già selezionato e resta modificabile.

Poi, in ordine:

• git init se serve;
• un .gitignore scritto per quel linguaggio se manca; a uno già presente accoda in fondo solo le cartelle di build che non esclude;
• se git traccia già file esclusi lo dice col conteggio e propone di toglierli dal tracciamento senza cancellarli dal disco;
• un README.md di partenza se manca;
• CLAUDE.md e AGENTS.md con le regole comuni, e images/screenshots/;
• add -A, commit, creazione del repository, origin, push e upstream.

Un origin già presente non viene mai sovrascritto: GitCode lo dice e chiede se fare push lì. Alla fine mostra l'indirizzo e si offre di aprirlo.

2 · Apri una chat AI sul web

Apre nel browser predefinito la chat che scegli fra quelle in elenco. Nessun comando, nessuna modifica al repository.

L'elenco arriva con Claude Code, ChatGPT/Codex, Gemini/Jules e GitHub Copilot, ma è tuo: da Modifica l'elenco aggiungi, rinomini e togli voci, e la scelta resta fra un avvio e l'altro. Un indirizzo senza https:// lo riceve da solo; tutto ciò che non è un indirizzo web viene rifiutato. Ripristina il predefinito rimette l'elenco di partenza.

3 · Unisci il lavoro dell'AI

Recupera il lavoro che una chat AI ha lasciato su un altro ramo, con o senza pull request. Fa fetch --prune, cerca i rami remoti diversi da main, ne usa uno se è l'unico oppure te li mostra con data e messaggio.

Ti fa vedere quanti commit sono avanti e quali file cambiano, e solo dopo la conferma fa checkout main, merge --no-ff, push, cancella il ramo remoto e riallinea. Su un conflitto si ferma, non risolve niente da solo e lascia il repository ispezionabile.

4 · Crea un progetto nuovo

Crea una cartella già funzionante nel linguaggio scelto e la apre in VS Code. Scegli linguaggio, cartella di destinazione e nome; GitCode scrive struttura e configurazione, e dove serve costruisce un ambiente vero:

• cargo init per Rust;
• dotnet new console per C#;
• per Python uv venv se uv è nel PATH, altrimenti py -m venv .venv, con VS Code già impostato per attivarlo.

Ogni progetto riceve git init -b main, .gitignore, README.md, CLAUDE.md e .progetto.json col linguaggio scelto. La cartella nuova diventa quella di lavoro. Si ferma se la destinazione contiene già qualcosa.

5 · Porta un progetto allo standard

Porta allo standard un progetto che GitCode non ha creato, in due modi:

• una cartella già su questo PC;
• un progetto che esiste solo su GitHub: incolli l'indirizzo e scegli dove clonarlo.

Riconosce il linguaggio come il pulsante 1, fa git init -b main solo se la cartella non è ancora un repository e scrive soltanto i file che mancano. Poi ricostruisce l'ambiente: uv o venv per Python, cargo fetch per Rust, dotnet restore per C#.

Un .venv già presente si rifà da zero solo se lo scegli nel riepilogo. Prima di scrivere qualsiasi cosa mostra tutto e aspetta conferma; nessun file esistente viene sovrascritto o riformattato.

Con la pubblicazione su sito accesa lo mette anche a norma per l'import del sito: schermate in images/screenshots/ numerate da 01, copertina, sito.json nel formato esatto che l'admin legge (feature con titolo e descrizione, stato e distribuzione fra i valori riconosciuti, manuale al posto di un rimando), README coi percorsi nuovi. Il registro dice cosa ha spostato e cosa manca ancora.

6 · Scatta le schermate a mano

Avvia il programma del progetto e raccoglie le schermate. Cerca l'eseguibile compilato sotto la cartella, altrimenti il comando ricordato nei metadati, altrimenti lo chiede e se lo ricorda.

Se il progetto è Rust o Tauri e non è compilato, si offre di compilarlo prima: scarica le librerie se mancano e aggiunge a package.json lo script che serve, facendo solo quello che manca. Se qualcosa non si può riparare lo dice in italiano nominando il file, non l'errore di npm.

Compare una barra sempre in primo piano, che si trascina dove vuoi e la volta dopo si ritrova lì. Si fotografa in due modi:

• premendo il tasto scelto: clicchi il campo sulla barra e premi il tasto che vuoi, e da quel momento è quello;
• cliccando Scatta, che fotografa la finestra subito dietro la barra.

Finché non scegli un tasto si prova F9, poi F8, F10, F7, e quello che ha vinto è scritto sulla barra. Se nessuno è libero la sessione parte comunque e fotografi con Scatta. Ogni scatto va in images/screenshots/ col numero successivo: niente viene mai sovrascritto.

Con Fine si apre il riepilogo con le miniature: scarti quelle che non vuoi, segni la copertina, e solo alla conferma si cancella, si rinumera da 01 senza buchi e si copia la copertina in /uploads/1788628459462-cover.png. Poi ti chiede se mandare le immagini su GitHub.

Se il programma da fotografare pretende i diritti di amministratore, GitCode lo dice e propone di riavviarsi elevato con la stessa cartella di lavoro.

Il pulsante 1 porta ogni cartella che tocca allo stesso standard: CLAUDE.md e AGENTS.md con lo stesso contenuto, cioè le regole valide per qualunque AI ci lavori, e images/ con images/screenshots/.

Su file già presenti riscrive solo il tratto fra i due segnaposto: quello scritto dall'utente resta. All'apertura di una cartella senza le regole propone di aggiungerle, e prima di pubblicare o adottare, se README.md, CLAUDE.md o AGENTS.md non sono in italiano, propone di riscriverli dai modelli senza mai farlo da solo.

Pubblica e il pulsante 1 dicono, senza fermarsi, se /uploads/1788628459462-cover.png manca o se images/screenshots/ è vuota; su un progetto col giro automatico non mandano a scattare a mano, perché le immagini le rifà la release successiva.

In fondo alla Configurazione c'è un interruttore, spento di default, per chi pubblica i propri software su un sito suo. Acceso aggiunge tre cose.

sito.json

I pulsanti 1, 4 e 5 scrivono anche sito.json nella radice, con i campi della scheda da compilare in italiano: nome, categoria, sottotitolo, stato, tipo e formato di distribuzione, tag, feature con titolo e descrizione, requisiti, documentazione, copertina, schermate. Un sito.json già compilato conserva i suoi valori e le sue chiavi in più; uno illeggibile viene messo da parte come sito.json.rotto.

Prepara per il sito

Fra i pulsanti numerati compare 2 · Prepara per il sito: copia negli appunti il comando che fa compilare sito.json e il README a un'AI dal codice vero e le fa scrivere il giro delle schermate dentro autoshot.js, poi apre il progetto in VS Code con davanti una pagina di istruzioni. Il comando è già negli appunti: si incolla in Claude Code con Ctrl+V. GitCode dà solo il meccanismo del giro — autoshot.rs, la variabile GITCODE_AUTOSHOT, i marcatori nel titolo, la cattura — e scrive autoshot.js soltanto se manca, come modello col protocollo nei commenti, senza mai sovrascriverlo. L'elenco delle finestre è del progetto: l'AI lo scrive dentro quel file, tutte le finestre nell'ordine della tabella delle schermate del README, un marcatore letterale SHOT:<numero>:<nome> per ognuna, mai un giro parallelo con altri comandi. Si fa una volta sola per progetto: quando sito.json e README sono compilati e autoshot.js ha più di un marcatore, il pulsante si spegne con la scritta «Già preparato». Da quel momento le schermate le rifà Pubblica, a ogni release.

Prima di partire, Prepara per il sito, Pubblica e la release controllano il contratto dell'import del sito e sistemano da soli quello che si può:

• le schermate vanno in images/screenshots/ con i nomi 01.png, 02.png…, prese da images/, screenshots/ o docs/ se stavano altrove, o rinumerate se avevano nomi qualunque;
• /uploads/1788628459462-cover.png si fa con la prima schermata se manca;
• sito.json viene riscritto nel formato esatto dell'import conservando ogni testo già scritto: le feature scritte come frasi diventano titolo più descrizione, il formato dell'installer finito nel campo della distribuzione va nel suo, stato e distribuzione si normalizzano, un manuale che è solo un rimando viene sostituito dal testo del README se è in italiano, copertina ed elenco delle schermate sono quelli veri;
• il README segue le immagini spostate e riceve la tabella delle schermate se non ne ha.

Un progetto già a norma non viene toccato. Quello che manca ancora e non si ricava dal codice (sottotitolo, categoria, manuale, tag, un giro coi marcatori costruiti a pezzi) sta nel registro riga per riga: sono le cose che scrive l'AI col comando di Prepara. Niente viene cancellato.

Il giro automatico delle schermate

Lo esegue Pubblica, a ogni release, sull'eseguibile appena compilato: il programma parte con GITCODE_AUTOSHOT=1 e si gira le schermate da solo:

• scrive SHOT:<numero>:<nome> nel titolo della finestra prima di ogni scatto;
• scrive SHOT:DONE alla fine e si chiude;
• GitCode fotografa a ogni marcatore: porta la finestra davanti, aspetta che abbia finito di ridimensionarsi e prende l'intera area client in pixel fisici, qualunque sia la scala di Windows; un'immagine che non ha la misura della finestra non si accetta;
• gli scatti finiscono in una cartella temporanea e solo a giro completo images/screenshots si svuota e le nuove entrano rinumerate da 01, mai un misto di vecchie e nuove; se il giro fallisce o scatta meno schermate dei marcatori dichiarati, non si cancella niente e il registro dice perché;
• la copertina si mette da sola se manca, e l'elenco in sito.json e nel README si aggiorna, tutto nella stessa release.

Prima di compilare GitCode controlla che il giro ci sia davvero nel codice, non che un interruttore dica di sì, e se manca scrive il modello nel progetto (per ora nei progetti Rust/Tauri), senza mai sovrascrivere un autoshot.js che c'è già. Su un progetto preparato le schermate non si saltano mai: se per qualche motivo si saltano, il registro dice esattamente perché — ed è lì che si legge anche quante schermate vecchie sono state cancellate, quante nuove scattate, dove sono finite e qual è la copertina. Attenzione a un caso: un programma che all'avvio si rilancia da sé (diritti di amministratore, istanza unica) fa ripartire un processo che non ha più la variabile del giro, e il giro non parte; GitCode prova a seguirlo comunque e, se non lo trova, lo scrive. Il pulsante 6, Scatta le schermate a mano, resta per gli scatti fatti dall'utente. Spegnere l'interruttore non cancella niente dai progetti.

Primo dei pulsanti numerati sotto la cartella c'è l'opzione A pagamento, facoltativa e spenta per ogni progetto. Accesa su un progetto Rust/Tauri, GitCode inserisce da solo il modulo licenze:

• src-tauri/src/licenza.rs con la chiave pubblica Ed25519 incorporata e lo slug del progetto come nome del prodotto;
• mod licenza; e i comandi licenza_stato e licenza_attiva in lib.rs;
• le dipendenze ed25519-dalek, uuid e base64 nel Cargo.toml, se mancano;
• la finestra di attivazione licenza.js nei file statici, nelle lingue che il progetto ha.

Al primo avvio il programma chiede la chiave XXXX-XXXX-XXXX-XXXX, la verifica una volta online sul sito e da lì in poi controlla offline il file di licenza firmato: senza licenza valida resta bloccato. Se il modulo c'è già l'opzione risulta accesa e non si inserisce niente due volte; sugli altri progetti è disattivata con la scritta «Per ora solo Rust/Tauri». Il registro scrive cosa è stato inserito.

Italiano, inglese, tedesco, francese e spagnolo, col selettore in alto a destra. La scelta resta fra un avvio e l'altro; alla prima apertura vale la lingua di Windows se è fra le cinque, altrimenti l'italiano. La Guida, accanto a Configurazione, ripercorre tutto questo passo passo in ogni lingua.

• Niente viene mai toccato senza il tuo sì, e ogni operazione mostra prima cosa farà.

• Sui conflitti si ferma e lascia il repository ispezionabile.

• Un attrezzo che manca non annulla tutto: quel passo viene saltato e te lo dice fra le note finali.

• Se git rifiuta la cartella perché di un altro utente Windows, un dialogo propone di autorizzarla con safe.directory e riprende da dove si era fermato.

• Le password non vengono mai chieste né salvate: l'accesso lo tiene gh nel portachiavi di Windows.

• Se origin punta a un repository che su GitHub non esiste più, Pubblica, la release e il pulsante 1 lo ricreano con lo stesso nome, rimandano ramo e tag, rimettono secret e workflow della copia pubblica e vanno avanti.