Guida agli spazi Git

Un repository Git di Flow è un repository vero (lo cloni e ci fai push col git che usi già) che vive dentro Flow invece che su un servizio esterno. Codice, task e pull request sono dove sono anche i tuoi file: stesso login, stessi membri e permessi, stessa copia di sicurezza, stessa istanza, europea o nella tua azienda.

È fatto per chi il codice non vuole (o non può) farlo uscire: il repository è uno spazio come gli altri, con i suoi membri e due ruoli (editor fa push, lettore clona e legge), più gli amministratori, che possono tutto. I repository compaiono nella sezione Repository della barra laterale e occupano spazio nella quota del piano come tutto il resto.

Nel browser trovi cinque schede: Codice, Commit, Tasks, Pull request e Accesso. Le prime due si guardano, le altre si usano: il lavoro di squadra (chi fa cosa, cosa entra nel ramo principale) succede lì.

Il clone e il push passano da HTTPS, con credenziali fatte apposta:

• nome utente = la tua email;
• password = una password Git, che ti crei da solo nella scheda Accesso del repository («Come collegarsi», col comando di clone già pronto da copiare).

La password si vede solo al momento della creazione: copiala nel gestore di credenziali di git (su Mac osxkeychain, su Windows Git Credential Manager) e non te la richiede più. Se la perdi non si recupera: ne crei un'altra e revochi la vecchia. Le tue password Git le vedi e le revochi in Account → Git; una password vale per tutti i repository a cui hai accesso, e per niente altro: non apre l'app e non vale per l'API.

Chi può fare cosa lo decide il ruolo nello spazio: editor fa push di rami e tag come su qualunque remoto, lettore solo clone e fetch. Chi non è membro il repository non lo vede proprio.

La scheda Codice mostra l'albero dei file al ramo scelto, e la home del repository apre il README della radice, come ti aspetti. I file di testo si leggono lì; per un binario o un file molto grande il browser non finge: ti dice di clonare.

La scheda Commit è la storia del ramo: ogni commit si apre sul suo diff. Dal testo di task e commenti, uno sha porta dritto al diff di quel commit.

Il browser è fatto per leggere e decidere: si scrive in locale, col proprio editor, e si fa push. L'unica scrittura che passa dal web è quella che deve passarci: fondere una pull request.

I task sono dove la squadra si parla: bug da sistemare, modifiche da chiedere, cose da fare, discussioni. Quattro tipi (Bug, Richiesta di modifica, To-do, Discussione) e per il resto la stessa forma: titolo, testo in Markdown, commenti, stato aperto/chiuso.

Ogni task ha un numero: scrivere #12 in un task, in un commento o in una pull request crea il collegamento; uno sha di commit diventa il link al suo diff. Un task può avere un assegnatario (fra i membri), etichette e una priorità; i filtri in testa alla lista («Aperti», «I miei task», la ricerca) servono a ritrovarsi quando i task diventano tanti.

Quello che non hai ancora letto si vede: il task con novità è in grassetto, e la scheda porta il contatore «da leggere». Le email seguono la tua preferenza in Account → Notifiche → Task: chi partecipa a un task (autore, assegnatario, chi ha commentato) riceve assegnazioni, commenti e chiusure.

A un task si allegano file: finiscono in una cartella «Task #n» dello spazio, e nel testo resta il riferimento. Utile per screenshot, log, documenti di partenza: sono nel repository di chi ci lavora, non in una chat esterna.

Una pull request propone di fondere un ramo in un altro. La apri scegliendo i due rami (una PR aperta per ramo alla volta), e la scheda ti dice subito e dal vivo come sta: «si fonde senza conflitti: n commit», oppure l'elenco dei file in conflitto, che risolvi in locale, e al push successivo la scheda si aggiorna.

Sotto ci sono i commit in arrivo e il diff completo. Si commenta in fondo o sulla singola riga del diff: ogni riga apre un filo con Rispondi e Risolvi, e i fili sulle righe che un nuovo push ha cambiato non si perdono: finiscono in coda, col loro percorso e numero di riga.

Le review danno il verdetto: Approva o Chiedi modifiche (mai sulla propria PR). Conta l'ultimo verdetto di ciascuno, e un'approvazione vale per la versione del ramo su cui è stata data: dopo un nuovo push è segnata «su una versione precedente» e non conta più.

Fondi dal web, scegliendo come entrano i commit:

• commit di merge: la storia resta com'è, con un commit di fusione firmato da chi preme;
• squash: tutti i commit schiacciati in uno solo, firmato da chi ha aperto la PR;
• rebase: i commit rimessi in fila sopra la destinazione, senza commit di merge.

C'è l'opzione «cancella il ramo dopo», e se invece fondi da terminale con git la PR se ne accorge da sola e si segna «Fusa con git».

Su un ramo protetto nessuno fa push diretto, nemmeno gli editor: chi ci prova riceve il rifiuto dal server, con scritto il perché. Nel ramo si entra in un modo solo: fondendo una pull request dal web.

Si protegge un ramo dalla scheda Accesso (serve un amministratore), e per ogni ramo si può chiedere un numero di approvazioni: la PR si fonde solo quando le review approvate sono abbastanza, e una review «chiedi modifiche» blocca finché non cambia. L'amministratore può fondere comunque: la regola disciplina la squadra, non gli toglie le chiavi.

È il modo di dire «su main si arriva solo con una PR rivista» e di farlo rispettare dal server invece che da un patto verbale.

Ogni push viene messo al sicuro subito, nello stesso archivio protetto dei tuoi file: copie ridondanti, controlli continui, ripristino automatico. Non c'è niente da configurare e niente da ricordarsi.

La pagina del repository ti dice quando è stata fatta l'ultima copia («Copia di sicurezza aggiornata alle…») e, se una copia non è riuscita, te lo scrive.

Nella quota del piano il repository pesa quanto pesa davvero, con la deduplicazione che vale per tutto il resto: un repository normale occupa poco.

La password Git apre anche una porta in più: le rotte API dei task e delle pull request (/api/repos/…/tasks e /api/repos/…/pulls). Con un curl autenticato (utente la tua email, password la password Git) si elencano i task, si legge una PR, si commenta, si allega un file a un task o a una PR. Solo quelle rotte: per il resto dell'API serve un token API vero (ne parla la pagina Sviluppatori).

Serve a chi automatizza il proprio flusso (script, strumenti di sviluppo, agenti) senza dare in giro credenziali più larghe del necessario: la password Git resta revocabile in un clic da Account → Git, e il suo perimetro è il lavoro sul repository.