GitHub per collaborare in gruppo - Prof-Matteo-Palitto-Peano/GPO-Software-Project GitHub Wiki

In questo post vedremo come possiamo migliorare le conoscenze su VCS (Version Control System) e rendere il nostro processo di sviluppo più strutturato per lavorare con un gruppo di colleghi.

• Organizzazioni
• Fork
• Richieste pull
• Processo di revisione del codice
• Distribuzione
• tag
• Distribuzioni (Releases)

Per poter collaborare con PARI POTERI allo stesso progetto, abbiamo bisogno di un progetto che non sia di qualcuno in particolare, ma di un gruppo di persone che in GitHub e' chiamato ORGANIZATION

L'organizzazione è come creare un gruppo in GitHub proprio come i gruppi in altri social media o piattaforme di messaggistica come Facebook, WhatsApp, Skype, ecc.

Nell'organizzazione ci saranno Amministratori che potranno gestire il gruppo, come aggiungere e eliminare membri, e membri ordinari che possono contribuire al progetto ma non gestirlo.

Cominciamo creando un'organizzazione.

Vai alla homepage di GitHub o fai clic qui per vedere la seguente schermata.

Devi prima accedere al tuo account di GitHub per poter vedere la schermata sopra. 😬

In alto a destra, hai questa +icona, facendo clic su di essa si aprirà questa finestra a discesa.

Clicca su "Crea nuova organizzazione " per creare una nuova organizzazione. 😑

Inserisci alcuni dettagli di base come il nome dell'organizzazione, l'ID e-mail, ecc. A partire da ora, puoi crearlo nel piano gratuito poiché non creeremo alcun progetto privato. Quando crei un'organizzazione per la tua azienda o un team in cui desideri mantenere privato il tuo progetto, devi configurare le impostazioni di pagamento in questo passaggio.

Non è necessario aggiungere altri membri a partire da ora, puoi farlo in qualsiasi momento nel momento successivo. Basta inserire gli altri dettagli obbligatori e completare la creazione di una nuova organizzazione.

Congratulazioni! Ora hai la tua organizzazione. 😎

Le organizzazioni possono avere progetti (repository) e membri. Quindi, dobbiamo creare un progetto nell'organizzazione per consentire alle altre persone di lavorare su di esso insieme a noi come una squadra.

Creiamo uno!

Nella home page della tua organizzazione, puoi vedere un pulsante chiamato " Nuovo ". Cliccandoci sopra si aprirà una finestra in cui è possibile inserire alcuni dettagli e creare un repository proprio come creare un repository con il nostro account. L'unica differenza è che il repository è di proprietà dell'organizzazione, NON TUO! anche se è stato creato da te...

Non ti preoccupare. Al momento sei l'unico amministratore della tua organizzazione.

Ma anche se sei amministratore, non ti sara' possibile inviare il tuo codice al repository appena creato nella tua organizzazione.

Come ho detto prima, il repository è di proprietà dell'organizzazione. Ciò significa che ogni membro che lavora ai progetti deve sapere cosa sta succedendo. Quello che puoi fare e' di suggerire le modifiche e inviarle come proposta. in modo che gli altri membri esaminino il codice e quando tutti lo approvano avremo l'opzione di memorizzarlo nel REPO.

Come si fa a proporre una modifica del codice? È qui che entra in gioco il Forking.

Un fork non è altro che una copia di un repository non tuo.

Mentre il REPO originale non e' tuo e non lo puoi modificare, la copia e' tua e puoi apportare tutte le modifiche che ritieni giuste

Nella homepage del progetto della tua organizzazione, puoi vedere un pulsante chiamato " Fork " in alto a destra, come mostrato di seguito.

Quando esegui il fork del repository appena creato nell'organizzazione, ti verrà chiesto con quale account desideri creare questo fork. Fai clic sul tuo account dove vedi il tuo nome utente e la tua foto del profilo. Ora hai la copia del repository della tua organizzazione sotto il tuo account. Si chiama il fork del repository dell'organizzazione.

Qual è la differenza tra un REPO ottenuto con il FORK e un tuo repository personale creato ex-novo?

Il fork è sempre collegato al repository originale che sia di altri o di organizzazioni. Quindi, una volta apportate delle modifiche, se vuoi, puoi proporle al repository genitore da cui hai fatto il fork.

Non è invece possibile proporre modifiche al codice ad altri repository dai repository creati ex-novo sul proprio account.

Ma come possiamo suggerire queste modifiche al repository dell'organizzazione?

La richiesta pull (PR dall'ingelse Pull Request) è il metodo di proposta di modifiche al codice nel repository principale o anche da un ramo all'altro nello stesso repository.

Ogni volta che lavori su una funzione o correggi un bug o anche qualche modifica casuale del codice, di solito fai un COMMIT del nuovo ​​codice e lo invii al CLOUD(GitHub) sul tuo repository personale (operazione di PUSH). Nel repository dell'organizzazione, non puoi semplicemente spingere le tue modifiche così come sono. Devi proporre la modifica agli altri membri dell'organizzazione, i quali devono poter analizzare e approvare la modifica proposta.

Quindi, non saresti l'unico a prendersi la colpa quando qualcosa andrà storto nel codice. 😝

Ma la richiesta pull non è solo una proposta di modifica. È un forum dedicato per discutere la modifica del codice proposto. Se ci fossero problemi con le modifiche o qualcosa deve essere discusso su alcune modifiche al codice, i membri dell'organizzazione possono inviare feedback nella richiesta pull e persino modificare il codice spingendo i commit di follow-up.

Vediamo come fare.

Clonare il repository fork sul computer locale. Crea un nuovo ramo, chiamiamolo NuovaFunzionee apporta alcune modifiche al codice nel ramo e invia il commit al tuo fork nel cloud.

Se non sai come farlo, fai riferimento al seguente articolo.

Ora apri il repository che hai FORKato nel browser. È possibile selezionare il RAMO su cui stai lavorando mediante il menu a tendina.

Seleziona il tuo nuovo ramo

Avvia una richiesta PULL facendo clic sul pulsante " Nuova richiesta pull " che trovi accanto al menu a discesa di selezione del ramo. Vedrai in anteprima la richiesta PULL che stai per innoltrare. Puoi modificare qualsiasi dettaglio, modificare il nome della richiesta PULL e cambiare il ramo principale a cui stai proponendo la modifica del codice. Una volta che sei sicuro di tutti i dettagli, fai clic su " Crea richiesta pull " per confermare la proposta.

In questo modo hai inviato una richiesta Pull al repository dell'organizzazione. Ora tutto ciò che bisogna fare è consentire a qualsiasi altro membro dell'organizzazione di visionare questa richiesta PULL condividendo il link di questo PR. Puoi semplicemente copiarlo dalla barra degli indirizzi del browser per condividerlo.

Quando si genera un PR, gli altri membri dell'organizzazione riesaminano le tue modifiche per assicurarsi che tu non abbia rimosso nessuna funzionalità esistente del progetto aggiungendo del codice aggiuntivo o rimuovendo del codice. 😝

Viceversa, dovrai esaminare le modifiche al codice dei tuoi compagni di squadra in modo da sapere cosa sta succedendo con il progetto.

Vediamo come avviene la revisione del codice:

Fai clic sulla scheda che dice " File modificati " come mostrato di seguito, che aprirà una pagina che mostra tutte le modifiche al codice.

Nell'immagine sopra, i codici mostrati in verde sono quelli che sono stati aggiunti al progetto e quelli mostrati in rosso vengono rimossi dal progetto. Inoltre, puoi vedere i simpboli+o - all'inizio di ogni riga.

Il revisore deve esaminare tutte le modifiche al codice e verificare che non presenti qualche errore che sia ovvio. In caso di errori o se qualcosa deve essere fatto in modo diverso, il revisore può lasciare un commento alla richiesta. GitHub ti da la possibilita' di lasciare un commento su qualsiasi riga del codice e indicherà la riga esatta a chiunque visualizzi la PR in seguito.

Passando il mouse sopra il codice, puoi vedere un pulsante di colore blu con l' icona (+) prima dell'inizio della riga, facendo clic su di essa si aprirà una casella di commento nella stessa riga. Puoi digitare qualsiasi cosa, taggare chiunque nell'organizzazione e puoi fare molte altre cose proprio come qualsiasi altra casella di commento. Anche gli emoji sono supportati. 😉

Quindi il richiedente della PR riceverà una notifica tramite e-mail e nelle notifiche GitHub. Il revisore, se volesse, può informare l'autore della proposta sulla chat/forum del PR per richiamare la sua attenzione immediata. Le conversazioni sul PR danno la possibilita' di chiarimenti, e se opprtuno, di apportare modifiche pertinenti con ulteriori COMMIT allo stesso ramo.

Nel caso nuove modifiche siano state apportate, come conseguenza della discussione, il processo di revisione dovra' essere ripetuto

Si prega di leggere questo articolo, su come la richiesta PULL e il processo di revisione del codice debbano essere eseguiti in modo educato e amichevole.

Una volta che tutto sembra a posto, il revisore deve approvare la richiesta PULL facendo clic sul pulsante " Rivedi modifiche " e inviare avendo prima selezionato l'opzione " Approva " come mostrato di seguito.

Una volta tutti i revisori danno la loro approvazione, l'autore della proposta avra' la possibilita' di memorizzare le modifiche sul progetto della organizzazione facendo clic sul pulsante " Invia Modifiche (Merge PULL Request) " come mostrato di seguito.

In realta' la richiesta di PULL non deve essere approvata da tutti gli altri revisori per essere inviata al repository dell'organizzazione, a meno che non sia stata configurata in questo modo. Quindi, potresti rivedere le modifiche tu stesso e memorizzarle con il ramo principale senza approvazione. Ma questo è altamente sconsigliato.

Nei progetti dell'organizzazione, ogni volta che apportiamo modifiche, potremmo voler distribuire il nuovo codice.

Non verra' trattta la fase di distribuzione in quanto ci sono tonnellate di risorse disponibili per ciascun fornitore di servizi sui loro siti Web ufficiali e altre risorse online. Vedremo solo come archiviare la vecchia versione del codice con l'uso di GIT (da non confodersi con GitHub) e come differenziare l'ultima versione rilasciata per semplificare il processo di distribuzione.

I tag non sono altro che un modo per distinguere una versione rilasciata dalle versioni precedenti e mantenere tutti i file delle versioni precedenti in un formato compresso come backup.

In un certo senso un TAG è simile ai rami usati durante la fase di sviluppo...

Nel nostro computer locale di lavoro, creiamo un tag eseguendo il comando seguente aprendo una finestra terminale nella directory del progetto.
git tag v1.0
v1.0 è il nome del tag qui. È proprio come un nome di ramo, puoi digitare qualsiasi cosa.

Spingiamo(PUSH) questo tag nel repository fork nel cloud.
git push origin v1.0
Il comando sopra spingerà/inviera' il tag sul tuo REPO ottenuto con il FORK del REPO dell'organizzazione, il che significa che hai inviato il file di backup nel tuo account GitHub. Il backup può essere recuperato e ripristinato in qualsiasi momento. Quando qualcosa andasse storto nel server che ospita l'appicazione, è possibile utilizzare questi tag per ripristinare la versione precedente del progetto. Di solito, i tag vengono inseriti nel repository dell'organizzazione anziché nel repository personale.

Quindi, come possiamo ripristinare un tag trasferito nel CLOUD?

Il comando git fetch originrecupererà tutti i rami come sai. Inoltre scaricherà tutti i tag sul tuo computer locale.

Potete vedere tutti i tag eseguendo il comando, git tag. Elencherà i nomi di tutti i tag nel tuo computer locale.

È possibile ripristinare un tag particolare utilizzando git checkout origin/v1.0proprio come il checkout a un ramo. Ripristinerà il codice dal tag v1.0 disponibile nel backup. Ora puoi procedere con la distribuzione del codice sul server dal tuo computer locale.

E' importante tenere traccia delle varie versioni che vengono distribuite, e quindi sapere quale versione e' stata distribuita per ultima

Puoi trovare una scheda chiamata " release " come mostrato di seguito.

Fare clic sulla scheda " Tag " come mostrato di seguito per visualizzare l'elenco dei tag finora trasferiti nel repository CLOUD.

Seleziona il tag che desideri nominare come ultima versione da distribuire. Quindi fai clic sul pulsante " Modifica tag " nell'angolo in alto a destra, come mostrato di seguito.

Compila i vari dettagli richiesti.

Digita qualsiasi nome nel campo " Titolo rilascio ", il nome del tag andrebbe bene. Quindi digita qualsiasi riepilogo su questa versione, se lo desideri, altrimenti lasciala vuota.

Vai avanti per registrare la versione per il rilascio.

Ora puoi vedere i dettagli di questo tag in alto contrassegnato come " Ultima versione " nella pagina " Rilasci " come mostrato di seguito.

Puoi seguire gli stessi passaggi per inviare un nuovo tag ogni volta che è necessario distribuire una nuova versione sul server cloud.