Firebase Studio e gestione del codice sorgente

La condivisione dei sorgenti ed il controllo di versione sono aspetti fondamentali nella gestione di progetti software. Considerando che Firebase Studio nasce come ambiente completo, essenzialmente un IDE potenziato con Intelligenza Artificiale, non può mancare un'adeguata integrazione con strumenti di gestione del codice.

L'approccio più naturale si ha con il mondo Git. Non appena si ottiene un progetto generato tramite prompt tutto ciò è rivelato dalla presenza di un file .gitignore (indica tutto ciò che deve essere ignorato nel caricamento su repository per motivi di privacy, sicurezza o utilità) compatibile con le tecnologie impiegate. Ad esempio, in un'applicazione web basata su Next.js potremmo trovare in .gitignore righe di questo tipo:

# dependencies
/node_modules
.yarn/*
...
...
# next.js
/.next/
/out/
...
...
# debug
npm-debug.log*
yarn-debug.log*
...
...
# vercel
.vercel
# typescript
*.tsbuildinfo
next-env.d.ts
.genkit/*

Finché non si procederà ancora al commit dei file non si avrà traccia invece della cartella .git che più di tutto denota la gestione del codice mediante il sistema Git.

Strumenti integrati in Firebase Studio

Tutto ciò che attiene alla gestione del codice sorgente verrà fatto ponendo l'ambiente in modalità Editor (non quello iniziale con prompt e preview, per intenderci). Qui si potrà agire essenzialmente in due modi:

• visuale: trattandosi di un ambiente che segue la scuola di Visual Studio Code nel menu verticale a sinistra troveremo un'icona che apre un pannello interamente dedicato alla gestione del codice;
• da riga di comando utilizzando un terminale che può essere aperto dal menu Terminal.

Nel primo caso si farà uso delle sezioni disponibili nell'IDE:

• Source Control Repository con le impostazioni dei collegamenti remoti;
• Source Control che elenca tutte le modifiche apportate al codice. Conviene sin dai primordi del progetto tenere d'occhio questa sezione per evitare che i cambianti divengano moltissimi nel giro di poco tempo;
• Source Control Graph è l'albero degli step principali che ha vissuto il codice sorgente. Interessante notare che in questa zona Firebase Studio, elencherà anche le indicazioni che abbiamo fornito noi tramite prompt legando così indissolubilmente l'evoluzione del progetto con la nostra interazione con l'Intelligenza Artificiale.

Agendo via terminale si seguiranno invece i tipici passi delle sessioni di lavoro con il comando git:

• git status per verificare lo stato del controllo di versione;
• git add per la presa in carico dei file da gestire (distinguendo se indicare i singoli file o l'asterisco per fare riferimento ad essi nel loro complesso);
• git commit per finalizzare il commit passando la descrizione anticipata dall'opzione -m;

Esempio di avvio alla gestione del codice

Vediamo ora l'avvio della gestione su un progetto con un semplice caso pratico che ricalca quanto fatto finora.

Diciamo che creiamo la nostra app degli aforismi con il seguente prompt (lo riportiamo per completezza e facilità di sperimentazione):

Crea un'app web che pubblichi un aforisma di un personaggio storico famoso riportando la frase in Italiano seguita dal nome dell'autore. Imposta un pulsante che serve a richiedere una nuova frase. Le frasi devono essere memorizzate staticamente in un file interno al progetto senza alcuna richiesta ad un modello di Intelligenza Artificiale.

Viene creato il nuovo progetto, vediamo l'anteprima e diciamo che il risultato ci soddisfa. Ora dobbiamo provvedere al collegamento del progetto con GitHub.

Se passiamo alla configurazione Editor, nella sezione dedicata al controllo di versione del codice troviamo il pulsante Publish branch che in questo caso coincide con il master.

A questo punto una finestra di alert ci avviserà che l'estensione GitHub vuole fare accesso sull'omonimo portale. Proseguendo ci verrà fornito un codice univoco per l'autenticazione su GitHub che potrà essere immesso seguendo le indicazioni (o comunque recandoci a questo indirizzo).

Fatto ciò il collegamento sarà fatto. Supponiamo ora di tornare al prompt e fare un'integrazione con

Cambia il colore del pulsante in arancione.

Al di là della modifica all'interfaccia, tornando al controllo del sorgente nell'Editor troveremo un pulsante come il seguente:

Ci sta avvisando che quello che manca da fare è il push del codice per fare in modo di allineare lo stato locale (quello che c'è in Firebase Studio) con quello remoto ovvero il repository. Se infatti a questo punto aprissimo un terminale e dessimo il comando git status ci verrebbe risposto:

On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)
nothing to commit, working tree clean

che significa essenzialmente la stessa cosa.

Come si vede il lavoro sui repository può essere svolto sia con i comandi git che con l'interfaccia visuale, l'importante è che questi non entrino in conflitto tra loro. Ad esempio, se c'è in corso una sincronizzazione avviata per via visuale, il comando git non potrà agire perché troverà il repository lockato.

I branch

Ai fini del percorso evolutivo del codice, i branch hanno una grande importanza e anche qui se ne può - come è naturale - fare uso. In basso a sinistra di Firebase Studio in modalità "Editor" troveremo l'indicazione del branch attuale ma cliccandolo si aprirà un menu in alto per le selezioni dei branch e la creazione di nuovi:

E' interessante notare come la gestione dei branch sia perfettamente evidente dall'anteprima dell'applicazione. Facciamo un esperimento. Visto che la nostra app mostra le citazioni in corsivo, creiamo (visualmente) un nuovo branch chiamandolo versione-senza-corsivo ed una volta passati a questo diamo con un prompt la seguente indicazione:

Modifichiamo l'interfaccia in modo che non appaia più niente scritto in corsivo.

In breve, avremo:

• un branch master che mostra un'anteprima con i testi in corsivo ed il controllo del codice che indica tutto committato e pushato in remoto
  

  Figura 4. Branch master

• un branch versione-senza-corsivo che indica l'esigenza di sincronizzare il progetto con il repository remoto ed un'anteprima con testo non italic
  
  

  Figura 5. Branch secondario

Si noti infine come nel pannello "Source Control Graph" i due branch mostrino evoluzioni diverse: nel master ci siamo fermati alla richiesta di cambio di colore al pulsante mentre nell'altro abbiamo eliminato lo stile corsivo dal testo (ma dobbiamo ancora eseguire la sincronizzazione remota).