Git
Uso quotidiano
Installazione
Se lavori su un computer Linux o MacOS git normalmente è già installato.
Per installarlo su Windows vai qui:
https://git-scm.com/downloads
Se avevi delle finestre del terminale aperte (anche su Visual Studio Code) chiudile e riaprile dopo l'installazione.
Dal prompt dei comandi configura git:git config --global user.name "Nome Cognome"
git config --global user.email "n.cognome@donboscosandona.it"
Molto utile anche installare su Code l'estensione Git Graph:
Creazione di un repository
Quando inizi un nuovo progetto crea per prima cosa un repository vuoto su GitHub, premendo il pulsante New:
Dai un nome al repository e scegli se renderlo pubblico (tutti possono vederlo) o privato (solo tu puoi vederlo e modificarlo).
Scegli anche di aggiungere un file readme in modo da non partire con un repository completamente vuoto (questo in alcune situazioni creava dei problemi con Visual Studio Code).
Il tuo repository è pronto, e premendo il pulsante Code puoi vederne l'URL, utile se vorrai clonarlo.
Clone
L'operazione Clone serve a scaricare una copia del repository nel tuo computer locale, in modo da poterci lavorare.
Questa copia manterrà un collegamento a GitHub: in questo modo sarà possibile inviare nel cloud le modifiche che farai ai file.
Da GitHub Premi il pulsante Code per vedere l'URL del repository: scegli la versione HTTPS e premi l'icona per copiare il percorso:
Da Visual Studio Code scegli "Clone Git Repository":
Se il pulsante non appare...
- Chiudi eventuali progetti già aperti su Code
- Verifica di aver installato correttamente Git sul tuo computer.
Incolla l'URL del repository e scegli "Clone from URL" (ti sarà richiesto di eseguire il processo di Autenticazione di GitHub se è la prima volta che ti colleghi da questo computer):
Ti sarà chiesto di scegliere una cartella nel tuo computer dove clonare il repository.
Riguardo ai nomi delle cartelle
Se stai clonando un repository che si chiama "rep-prova" non serve che tu crei nel tuo computer una cartella con questo nome: scegliendo la cartella Documenti, Desktop o altro, git per prima cosa creerà al suo interno una cartella col nome del progetto, dopodiché scaricherà i file al suo interno.
Al termine potrai scegliere di aprirlo dal pannello che compare in basso a destra:
Se il pannello non compare...
Dal menù File di Code scegli Apri cartella e vai ad aprire la cartella in cui ha fatto il clone.
A questo punto su Code dovresti vedere i file del tuo repository (inizialmente solo il file README.md) e potrai iniziare a lavorarci:
Modifica dei file
Lavora liberamente nel tuo repository.
Nota che quando modifichi un file, le righe modificate o aggiunte vengono evidenziate accanto ai numeri di riga:
Se clicchi su questi evidenziatori ti compare un dettaglio delle modifiche fatte:
Nell'explorer vengono evidenziati i file modificati (M) o creati (U):
Nella sezione Source Control avrai la possibilità di annullare tutte le modifiche fatte o quelle fatte a un singolo file premendo l'icona della freccia che torna indietro (Revert):
Cliccando col tasto destro sul nome di un file e scegliendo Open Changes puoi vedere il confronto tra la versione iniziale del file e quella con le modifiche fatte:
Da Git Graph puoi vedere la situazione attuale del repository:
Qui vediamo 2 modifiche che per ora non sono state salvate nel sistema di versioning di Git (Uncommitted Changes) che provengono dal ramo main (principale) del repository.
Commit e sincronizzazione
Ogni tanto nel corso del tuo sviluppo, puoi salvare la situazione delle modifiche fatte creando un "Commit".
È una buona pratica fare un commit ogni volta che hai terminato di aggiornare una certa parte del tuo sito o della tua applicazione: in questo se ti accorgerai di aver commesso degli errori potrai tornare a una versione precedente. Nei progetti condivisi questo è utile anche per vedere quali modifiche sono state fatte da altri sviluppatori.
Per fare un commit vai nel pannello Source Control e scegli un commento per il commit: il commento dev'essere qualcosa di breve che ti faccia capire in sintesi di che modifiche si tratta:
Premi poi il pulsante Commit: vedrai che la lista dei file modificati scompare da Source Control, perché adesso le modifiche sono state incorporate nella versione corrente del repository.
Nota anche che nella parte inferiore è comparso il numero 1 vicino alla freccia dei commit non sincronizzati: questo ti informa che il commit è presente nel tuo computer locale, ma non è stato ancora sincronizzato col repository remoto su GitHub.
La situazione su Git Graph è questa:
A differenza di prima ora le modifiche hanno una descrizione, e sulla destra puoi vedere l'autore del commit e il codice di hash che lo identifica (ad es. ac7091de).
Push
Procedi pure con la sincronizzazione del commit con GitHub. Questa operazione viene detta "Push".
Puoi farla sia premendo l'icona sulla barra distato:
Dopo aver fatto la sincronizzazione la situazione mostrata da Git Graph è questa:
Qui vediamo che (origin/main), cioè il repository principale su GitHub, si è allineato con il nostro repository locale (main).
Andando a curiosare sul sito di GitHub vedrai che le modifiche sono state riportate effettivamente anche lì:
Nei progetti condivisi questa funzionalità è molto utile, perché ti permette di vedere direttamente dal sito su quali file stanno lavorando gli altri sviluppatori.
Pull
L'operazione di Push invia le modifiche al cloud di GitHub, ma premendo il pulsante di sincronizzazione viene contestualmente avviata anche un'operazione di Pull, che va a scaricare eventuali aggiornamenti trovati sul repository (utile ad esempio se qualche altro sviluppatore nel frattempo ha modificato dei file).
Merge
Se per caso le tue modifiche dovessero andare in conflitto con quelle fatte da qualcun altro sullo stesso file, viene avviata un'operazione di merge (fusione) delle modifiche: Git prova a incorporare le modifiche di entrambi, e nel caso non ci riesca (quando ad esempio entrambi hanno modificato la stessa riga) ti chiede un aiuto, e devi scegliere se tenere le tue modifiche o quelle dell'altro sviluppatore, procedendo anche a un nuovo commit che risolve la situazione.
Branch
Quando si lavora a una nuova funzionalità, o alla correzione di un bug, è buona regola aprire un nuovo ramo (branch):
È facile comprendere che si tratta di un ramo importante, che non dovrà contenere modifiche fatte a metà, ma solo cose definitive.
Mentre gli utenti hanno accesso a questa versione dell'applicazione, gli sviluppatori devono poter lavorare a delle modifiche (bugfix = correzione di bug / feature = nuove funzionalità) ma queste modifiche possono richiedere giorni, lo sviluppatore può iniziare con un'idea e poi rendersi conto di aver commesso degli errori, ripararli e così via.
Solo quando sarà soddisfatto caricherà le modifiche anche nel ramo principale.
Vediamo come si fa in pratica.
Creare un nuovo ramo
Nella barra di stato compare il nome del ramo sul quale stai attualmente lavorando (main):
Premi su main e scegli "Create new branch":
Scegli per il nuovo ramo un nome che ti aiuti ad identificarlo. Per esempio supponiamo di voler lavorare a una nuova pagina dei contatti:
Fatto questo la barra di stato ti mostra che stai lavorando sul ramo "contatti":
e Code ti da la possibilità di pubblicare il ramo anche su GitHub:
Git Graph mostra questa situazione:
Proviamo allora a creare questo nuovo file:
La situazione è questa:
E dopo un commit:
Passare a un altro ramo
Supponiamo di dover tornare al ramo main per sistemare una cosa urgente, mettendo per un po' da parte la nuova funzionalità dei contatti.
Per farlo clicchiamo col tasto destro su main nel pannello di Git Graph e scegliamo Checkout Branch:
La barra di stato mostra:
...e in explorer il nuovo file è scomparso:
Facciamo delle modifiche a README:
Procediamo quindi a un commit. La situazione è questa:
Graph mostra che main è avanzato di un passo (Modifica urgente a Readme) mentre contatti è rimasto dove lo avevamo lasciato.
Proseguire il lavoro sulla nuova feature
Proviamo a tornare con un checkout a contatti, modifichiamolo ancora e facciamo un ulteriore commit:
Nota che i colori sono cambiati: il ramo sul quale stai lavorando è azzurro, mentre main è segnato in fucsia.
Incorporare le modifiche in main
Ora che abbiamo terminato lo sviluppo della nuova feature contatti, vogliamo incorporarla nel ramo principale, in modo che possa essere messa in produzione.
Per prima cosa facciamo un checkout del ramo main:
A questo punto, su Graph, clicchiamo col tasto destro sul commit della versione definitiva dei contatti e scegliamo "Merge into current branch"(unisci al ramo corrente):
Alla richiesta di conferma procediamo creando anche un nuovo commit:
La situazione finale è questa: appare chiaro che le modifiche del ramo contatti sono state incorporate nel ramo principale:
Un po' di pulizia
A questo punto il ramo contatti non ci serve più, e se vogliamo possiamo anche eliminarlo cliccando col tasto destro e scegliendo Delete Branch:
Alla richiesta di conferma possiamo scegliere di eliminare il ramo anche dal repository remoto (GitHub):
Tutti i commit fatti rimangono a tua disposizione, nel caso dovessi andare a cercare delle modifiche fatte:
Il ramo contatti però non esiste più, così se un giorno volessi nuovamente lavorare sui contatti e riaprire un branch con lo stesso nome potresti farlo.
Workflow
Ecco come si procede normalmente:
Si mantiene il ramo master (main) per la versione di produzione: sarà quella che vedranno gli utenti.
Nel caso sia necessaria la correzione urgente di un bug si lavora direttamente sul master creando un hotfix (correzione a caldo).
Si mantiene un secondo ramo develop con la versione di sviluppo dell'applicazione: sarà quella che vedranno gli sviluppatori, e da questa partiranno per fare le loro modifiche.
Le feature vengono sviluppate in rami temporanei che poi vengono uniti al ramo develop.
Di tanto in tanto il ramo di sviluppo viene unito al master, e si ha il rilascio di una nuova versione dell'applicazione.
Contribuire a un progetto
Proporre modifiche
Importante: nomi dei file
Il server Linux su cui sono ospitati i siti veri e propri fa distinzione tra lettere maiuscole e minuscole nei nomi dei file. Per Windows invece maiuscole e minuscole sono indifferenti. Per evitare problemi conveniamo di denominare sempre i file delle immagini, ecc. con lettere solo minuscole.
Per i file contenenti i componenti di React usiamo invece sempre l'iniziale maiuscola come di consueto.
Preparativi
Rami
Il repository contiene vari branch (rami):
- main: ramo principale, qui vengono caricati gli aggiornamenti ai componenti
- donboscosandona, inoratorio, per: rami per il sito della scuola, dell'oratorio e della proposta estate
- $bar, $piscina, ecc.: sono i rami per i nostri clienti virtuali, tutti preceduti dal simbolo $
- cognome-sito-modifica: sono rami temporanei creati da chi contribuisce ai vari progetti
Clona il repository e apri il ramo sul quale devi fare modifiche:
Crea a partire da questo un nuovo ramo:
Denomina il ramo in questo modo:cognome-sito-modifica
Esempio:
- Armando Solighetto...
- ...sul sito della gelateria...
- ...è incaricato di aggiornare il listino prezzi
Il nome del ramo potrebbe essere:
Passa al ramo appena creato:
Modifiche
Fai tutte le modifiche necessarie ai file.
Dopo aver controllato che sia tutto a posto, crea un commit:
Nota: puoi anche creare dei commit intermedi se lo desideri, mentre fai singole modifiche e non sei ancora pronto a inviare il lavoro finito.
Pull request
Quando sei pronto a inviare le modifiche apri una pull request:
Compila con attenzione la richiesta
E' importantissimo specificare con attenzione il ramo di destinazione (gelateria) sul quale le modifiche dovranno essere salvate.
Ora la tua richiesta sarà inviata al prof per l'approvazione:
Il messaggio "Branch Protection policy..." è normale e indica che la richiesta dovrà essere approvata.
Se il prof approverà la richiesta non dovrai più fare nulla, se invece ti scriverà chiedendo delle modifiche dovrai farle rimanendo sempre sul ramo e sulla pull request che hai creato e aggiungendo un ulteriore commit.
Se lavori su un computer Linux o MacOS git normalmente è già installato.
Per installarlo su Windows vai qui:
https://git-scm.com/downloads
Se avevi delle finestre del terminale aperte (anche su Visual Studio Code) chiudile e riaprile dopo l'installazione.
Dal prompt dei comandi configura git:
git config --global user.name "Nome Cognome" git config --global user.email "n.cognome@donboscosandona.it"
Molto utile anche installare su Code l'estensione Git Graph:
Creazione di un repository
Quando inizi un nuovo progetto crea per prima cosa un repository vuoto su GitHub, premendo il pulsante New:
Dai un nome al repository e scegli se renderlo pubblico (tutti possono vederlo) o privato (solo tu puoi vederlo e modificarlo).
Scegli anche di aggiungere un file readme in modo da non partire con un repository completamente vuoto (questo in alcune situazioni creava dei problemi con Visual Studio Code).
Il tuo repository è pronto, e premendo il pulsante Code puoi vederne l'URL, utile se vorrai clonarlo.
Clone
L'operazione Clone serve a scaricare una copia del repository nel tuo computer locale, in modo da poterci lavorare.
Questa copia manterrà un collegamento a GitHub: in questo modo sarà possibile inviare nel cloud le modifiche che farai ai file.
Da GitHub Premi il pulsante Code per vedere l'URL del repository: scegli la versione HTTPS e premi l'icona per copiare il percorso:
Da Visual Studio Code scegli "Clone Git Repository":
Se il pulsante non appare...
- Chiudi eventuali progetti già aperti su Code
- Verifica di aver installato correttamente Git sul tuo computer.
Incolla l'URL del repository e scegli "Clone from URL" (ti sarà richiesto di eseguire il processo di Autenticazione di GitHub se è la prima volta che ti colleghi da questo computer):
Ti sarà chiesto di scegliere una cartella nel tuo computer dove clonare il repository.
Riguardo ai nomi delle cartelle
Se stai clonando un repository che si chiama "rep-prova" non serve che tu crei nel tuo computer una cartella con questo nome: scegliendo la cartella Documenti, Desktop o altro, git per prima cosa creerà al suo interno una cartella col nome del progetto, dopodiché scaricherà i file al suo interno.
Al termine potrai scegliere di aprirlo dal pannello che compare in basso a destra:
Se il pannello non compare...
Dal menù File di Code scegli Apri cartella e vai ad aprire la cartella in cui ha fatto il clone.
A questo punto su Code dovresti vedere i file del tuo repository (inizialmente solo il file README.md) e potrai iniziare a lavorarci:
Modifica dei file
Lavora liberamente nel tuo repository.
Nota che quando modifichi un file, le righe modificate o aggiunte vengono evidenziate accanto ai numeri di riga:
Se clicchi su questi evidenziatori ti compare un dettaglio delle modifiche fatte:
Nell'explorer vengono evidenziati i file modificati (M) o creati (U):
Nella sezione Source Control avrai la possibilità di annullare tutte le modifiche fatte o quelle fatte a un singolo file premendo l'icona della freccia che torna indietro (Revert):
Cliccando col tasto destro sul nome di un file e scegliendo Open Changes puoi vedere il confronto tra la versione iniziale del file e quella con le modifiche fatte:
Da Git Graph puoi vedere la situazione attuale del repository:
Qui vediamo 2 modifiche che per ora non sono state salvate nel sistema di versioning di Git (Uncommitted Changes) che provengono dal ramo main (principale) del repository.
Commit e sincronizzazione
Ogni tanto nel corso del tuo sviluppo, puoi salvare la situazione delle modifiche fatte creando un "Commit".
È una buona pratica fare un commit ogni volta che hai terminato di aggiornare una certa parte del tuo sito o della tua applicazione: in questo se ti accorgerai di aver commesso degli errori potrai tornare a una versione precedente. Nei progetti condivisi questo è utile anche per vedere quali modifiche sono state fatte da altri sviluppatori.
Per fare un commit vai nel pannello Source Control e scegli un commento per il commit: il commento dev'essere qualcosa di breve che ti faccia capire in sintesi di che modifiche si tratta:
Premi poi il pulsante Commit: vedrai che la lista dei file modificati scompare da Source Control, perché adesso le modifiche sono state incorporate nella versione corrente del repository.
Nota anche che nella parte inferiore è comparso il numero 1 vicino alla freccia dei commit non sincronizzati: questo ti informa che il commit è presente nel tuo computer locale, ma non è stato ancora sincronizzato col repository remoto su GitHub.
La situazione su Git Graph è questa:
A differenza di prima ora le modifiche hanno una descrizione, e sulla destra puoi vedere l'autore del commit e il codice di hash che lo identifica (ad es. ac7091de).
Push
Procedi pure con la sincronizzazione del commit con GitHub. Questa operazione viene detta "Push".
Puoi farla sia premendo l'icona sulla barra distato:
Dopo aver fatto la sincronizzazione la situazione mostrata da Git Graph è questa:
Qui vediamo che (origin/main), cioè il repository principale su GitHub, si è allineato con il nostro repository locale (main).
Andando a curiosare sul sito di GitHub vedrai che le modifiche sono state riportate effettivamente anche lì:
Nei progetti condivisi questa funzionalità è molto utile, perché ti permette di vedere direttamente dal sito su quali file stanno lavorando gli altri sviluppatori.
Pull
L'operazione di Push invia le modifiche al cloud di GitHub, ma premendo il pulsante di sincronizzazione viene contestualmente avviata anche un'operazione di Pull, che va a scaricare eventuali aggiornamenti trovati sul repository (utile ad esempio se qualche altro sviluppatore nel frattempo ha modificato dei file).
Merge
Se per caso le tue modifiche dovessero andare in conflitto con quelle fatte da qualcun altro sullo stesso file, viene avviata un'operazione di merge (fusione) delle modifiche: Git prova a incorporare le modifiche di entrambi, e nel caso non ci riesca (quando ad esempio entrambi hanno modificato la stessa riga) ti chiede un aiuto, e devi scegliere se tenere le tue modifiche o quelle dell'altro sviluppatore, procedendo anche a un nuovo commit che risolve la situazione.
Branch
Quando si lavora a una nuova funzionalità, o alla correzione di un bug, è buona regola aprire un nuovo ramo (branch):
È facile comprendere che si tratta di un ramo importante, che non dovrà contenere modifiche fatte a metà, ma solo cose definitive.
Mentre gli utenti hanno accesso a questa versione dell'applicazione, gli sviluppatori devono poter lavorare a delle modifiche (bugfix = correzione di bug / feature = nuove funzionalità) ma queste modifiche possono richiedere giorni, lo sviluppatore può iniziare con un'idea e poi rendersi conto di aver commesso degli errori, ripararli e così via.
Solo quando sarà soddisfatto caricherà le modifiche anche nel ramo principale.
Vediamo come si fa in pratica.
Creare un nuovo ramo
Nella barra di stato compare il nome del ramo sul quale stai attualmente lavorando (main):
Premi su main e scegli "Create new branch":
Scegli per il nuovo ramo un nome che ti aiuti ad identificarlo. Per esempio supponiamo di voler lavorare a una nuova pagina dei contatti:
Fatto questo la barra di stato ti mostra che stai lavorando sul ramo "contatti":
e Code ti da la possibilità di pubblicare il ramo anche su GitHub:
Git Graph mostra questa situazione:
Proviamo allora a creare questo nuovo file:
La situazione è questa:
E dopo un commit:
Passare a un altro ramo
Supponiamo di dover tornare al ramo main per sistemare una cosa urgente, mettendo per un po' da parte la nuova funzionalità dei contatti.
Per farlo clicchiamo col tasto destro su main nel pannello di Git Graph e scegliamo Checkout Branch:
La barra di stato mostra:
...e in explorer il nuovo file è scomparso:
Facciamo delle modifiche a README:
Procediamo quindi a un commit. La situazione è questa:
Graph mostra che main è avanzato di un passo (Modifica urgente a Readme) mentre contatti è rimasto dove lo avevamo lasciato.
Proseguire il lavoro sulla nuova feature
Proviamo a tornare con un checkout a contatti, modifichiamolo ancora e facciamo un ulteriore commit:
Nota che i colori sono cambiati: il ramo sul quale stai lavorando è azzurro, mentre main è segnato in fucsia.
Incorporare le modifiche in main
Ora che abbiamo terminato lo sviluppo della nuova feature contatti, vogliamo incorporarla nel ramo principale, in modo che possa essere messa in produzione.
Per prima cosa facciamo un checkout del ramo main:
A questo punto, su Graph, clicchiamo col tasto destro sul commit della versione definitiva dei contatti e scegliamo "Merge into current branch"(unisci al ramo corrente):
Alla richiesta di conferma procediamo creando anche un nuovo commit:
La situazione finale è questa: appare chiaro che le modifiche del ramo contatti sono state incorporate nel ramo principale:
Un po' di pulizia
A questo punto il ramo contatti non ci serve più, e se vogliamo possiamo anche eliminarlo cliccando col tasto destro e scegliendo Delete Branch:
Alla richiesta di conferma possiamo scegliere di eliminare il ramo anche dal repository remoto (GitHub):
Tutti i commit fatti rimangono a tua disposizione, nel caso dovessi andare a cercare delle modifiche fatte:
Il ramo contatti però non esiste più, così se un giorno volessi nuovamente lavorare sui contatti e riaprire un branch con lo stesso nome potresti farlo.
Workflow
Ecco come si procede normalmente:
Si mantiene il ramo master (main) per la versione di produzione: sarà quella che vedranno gli utenti.
Nel caso sia necessaria la correzione urgente di un bug si lavora direttamente sul master creando un hotfix (correzione a caldo).
Si mantiene un secondo ramo develop con la versione di sviluppo dell'applicazione: sarà quella che vedranno gli sviluppatori, e da questa partiranno per fare le loro modifiche.
Le feature vengono sviluppate in rami temporanei che poi vengono uniti al ramo develop.
Di tanto in tanto il ramo di sviluppo viene unito al master, e si ha il rilascio di una nuova versione dell'applicazione.
Contribuire a un progetto
Proporre modifiche
Importante: nomi dei file
Il server Linux su cui sono ospitati i siti veri e propri fa distinzione tra lettere maiuscole e minuscole nei nomi dei file. Per Windows invece maiuscole e minuscole sono indifferenti. Per evitare problemi conveniamo di denominare sempre i file delle immagini, ecc. con lettere solo minuscole.
Per i file contenenti i componenti di React usiamo invece sempre l'iniziale maiuscola come di consueto.
Preparativi
Rami
Il repository contiene vari branch (rami):
- main: ramo principale, qui vengono caricati gli aggiornamenti ai componenti
- donboscosandona, inoratorio, per: rami per il sito della scuola, dell'oratorio e della proposta estate
- $bar, $piscina, ecc.: sono i rami per i nostri clienti virtuali, tutti preceduti dal simbolo $
- cognome-sito-modifica: sono rami temporanei creati da chi contribuisce ai vari progetti
Clona il repository e apri il ramo sul quale devi fare modifiche:
Crea a partire da questo un nuovo ramo:
Denomina il ramo in questo modo:cognome-sito-modifica
Esempio:
- Armando Solighetto...
- ...sul sito della gelateria...
- ...è incaricato di aggiornare il listino prezzi
Il nome del ramo potrebbe essere:
Passa al ramo appena creato:
Modifiche
Fai tutte le modifiche necessarie ai file.
Dopo aver controllato che sia tutto a posto, crea un commit:
Nota: puoi anche creare dei commit intermedi se lo desideri, mentre fai singole modifiche e non sei ancora pronto a inviare il lavoro finito.
Pull request
Quando sei pronto a inviare le modifiche apri una pull request:
Compila con attenzione la richiesta
E' importantissimo specificare con attenzione il ramo di destinazione (gelateria) sul quale le modifiche dovranno essere salvate.
Ora la tua richiesta sarà inviata al prof per l'approvazione:
Il messaggio "Branch Protection policy..." è normale e indica che la richiesta dovrà essere approvata.
Se il prof approverà la richiesta non dovrai più fare nulla, se invece ti scriverà chiedendo delle modifiche dovrai farle rimanendo sempre sul ramo e sulla pull request che hai creato e aggiungendo un ulteriore commit.
Quando inizi un nuovo progetto crea per prima cosa un repository vuoto su GitHub, premendo il pulsante New:
Dai un nome al repository e scegli se renderlo pubblico (tutti possono vederlo) o privato (solo tu puoi vederlo e modificarlo).
Dai un nome al repository e scegli se renderlo pubblico (tutti possono vederlo) o privato (solo tu puoi vederlo e modificarlo).
Scegli anche di aggiungere un file readme in modo da non partire con un repository completamente vuoto (questo in alcune situazioni creava dei problemi con Visual Studio Code).
Il tuo repository è pronto, e premendo il pulsante Code puoi vederne l'URL, utile se vorrai clonarlo.
L'operazione Clone serve a scaricare una copia del repository nel tuo computer locale, in modo da poterci lavorare.
Questa copia manterrà un collegamento a GitHub: in questo modo sarà possibile inviare nel cloud le modifiche che farai ai file.
Da GitHub Premi il pulsante Code per vedere l'URL del repository: scegli la versione HTTPS e premi l'icona per copiare il percorso:
Da Visual Studio Code scegli "Clone Git Repository":
Questa copia manterrà un collegamento a GitHub: in questo modo sarà possibile inviare nel cloud le modifiche che farai ai file.
Da GitHub Premi il pulsante Code per vedere l'URL del repository: scegli la versione HTTPS e premi l'icona per copiare il percorso:
Da Visual Studio Code scegli "Clone Git Repository":
Se il pulsante non appare...
- Chiudi eventuali progetti già aperti su Code
- Verifica di aver installato correttamente Git sul tuo computer.
Incolla l'URL del repository e scegli "Clone from URL" (ti sarà richiesto di eseguire il processo di Autenticazione di GitHub se è la prima volta che ti colleghi da questo computer):
Ti sarà chiesto di scegliere una cartella nel tuo computer dove clonare il repository.
Riguardo ai nomi delle cartelle
Se stai clonando un repository che si chiama "rep-prova" non serve che tu crei nel tuo computer una cartella con questo nome: scegliendo la cartella Documenti, Desktop o altro, git per prima cosa creerà al suo interno una cartella col nome del progetto, dopodiché scaricherà i file al suo interno.
Al termine potrai scegliere di aprirlo dal pannello che compare in basso a destra:
Se il pannello non compare...
Dal menù File di Code scegli Apri cartella e vai ad aprire la cartella in cui ha fatto il clone.
A questo punto su Code dovresti vedere i file del tuo repository (inizialmente solo il file README.md) e potrai iniziare a lavorarci:
Modifica dei file
Lavora liberamente nel tuo repository.
Nota che quando modifichi un file, le righe modificate o aggiunte vengono evidenziate accanto ai numeri di riga:
Se clicchi su questi evidenziatori ti compare un dettaglio delle modifiche fatte:
Nell'explorer vengono evidenziati i file modificati (M) o creati (U):
Nella sezione Source Control avrai la possibilità di annullare tutte le modifiche fatte o quelle fatte a un singolo file premendo l'icona della freccia che torna indietro (Revert):
Cliccando col tasto destro sul nome di un file e scegliendo Open Changes puoi vedere il confronto tra la versione iniziale del file e quella con le modifiche fatte:
Da Git Graph puoi vedere la situazione attuale del repository:
Qui vediamo 2 modifiche che per ora non sono state salvate nel sistema di versioning di Git (Uncommitted Changes) che provengono dal ramo main (principale) del repository.
Commit e sincronizzazione
Ogni tanto nel corso del tuo sviluppo, puoi salvare la situazione delle modifiche fatte creando un "Commit".
È una buona pratica fare un commit ogni volta che hai terminato di aggiornare una certa parte del tuo sito o della tua applicazione: in questo se ti accorgerai di aver commesso degli errori potrai tornare a una versione precedente. Nei progetti condivisi questo è utile anche per vedere quali modifiche sono state fatte da altri sviluppatori.
Per fare un commit vai nel pannello Source Control e scegli un commento per il commit: il commento dev'essere qualcosa di breve che ti faccia capire in sintesi di che modifiche si tratta:
Premi poi il pulsante Commit: vedrai che la lista dei file modificati scompare da Source Control, perché adesso le modifiche sono state incorporate nella versione corrente del repository.
Nota anche che nella parte inferiore è comparso il numero 1 vicino alla freccia dei commit non sincronizzati: questo ti informa che il commit è presente nel tuo computer locale, ma non è stato ancora sincronizzato col repository remoto su GitHub.
La situazione su Git Graph è questa:
A differenza di prima ora le modifiche hanno una descrizione, e sulla destra puoi vedere l'autore del commit e il codice di hash che lo identifica (ad es. ac7091de).
Push
Procedi pure con la sincronizzazione del commit con GitHub. Questa operazione viene detta "Push".
Puoi farla sia premendo l'icona sulla barra distato:
Dopo aver fatto la sincronizzazione la situazione mostrata da Git Graph è questa:
Qui vediamo che (origin/main), cioè il repository principale su GitHub, si è allineato con il nostro repository locale (main).
Andando a curiosare sul sito di GitHub vedrai che le modifiche sono state riportate effettivamente anche lì:
Nei progetti condivisi questa funzionalità è molto utile, perché ti permette di vedere direttamente dal sito su quali file stanno lavorando gli altri sviluppatori.
Pull
L'operazione di Push invia le modifiche al cloud di GitHub, ma premendo il pulsante di sincronizzazione viene contestualmente avviata anche un'operazione di Pull, che va a scaricare eventuali aggiornamenti trovati sul repository (utile ad esempio se qualche altro sviluppatore nel frattempo ha modificato dei file).
Merge
Se per caso le tue modifiche dovessero andare in conflitto con quelle fatte da qualcun altro sullo stesso file, viene avviata un'operazione di merge (fusione) delle modifiche: Git prova a incorporare le modifiche di entrambi, e nel caso non ci riesca (quando ad esempio entrambi hanno modificato la stessa riga) ti chiede un aiuto, e devi scegliere se tenere le tue modifiche o quelle dell'altro sviluppatore, procedendo anche a un nuovo commit che risolve la situazione.
Branch
Quando si lavora a una nuova funzionalità, o alla correzione di un bug, è buona regola aprire un nuovo ramo (branch):
È facile comprendere che si tratta di un ramo importante, che non dovrà contenere modifiche fatte a metà, ma solo cose definitive.
Mentre gli utenti hanno accesso a questa versione dell'applicazione, gli sviluppatori devono poter lavorare a delle modifiche (bugfix = correzione di bug / feature = nuove funzionalità) ma queste modifiche possono richiedere giorni, lo sviluppatore può iniziare con un'idea e poi rendersi conto di aver commesso degli errori, ripararli e così via.
Solo quando sarà soddisfatto caricherà le modifiche anche nel ramo principale.
Vediamo come si fa in pratica.
Creare un nuovo ramo
Nella barra di stato compare il nome del ramo sul quale stai attualmente lavorando (main):
Premi su main e scegli "Create new branch":
Scegli per il nuovo ramo un nome che ti aiuti ad identificarlo. Per esempio supponiamo di voler lavorare a una nuova pagina dei contatti:
Fatto questo la barra di stato ti mostra che stai lavorando sul ramo "contatti":
e Code ti da la possibilità di pubblicare il ramo anche su GitHub:
Git Graph mostra questa situazione:
Proviamo allora a creare questo nuovo file:
La situazione è questa:
E dopo un commit:
Passare a un altro ramo
Supponiamo di dover tornare al ramo main per sistemare una cosa urgente, mettendo per un po' da parte la nuova funzionalità dei contatti.
Per farlo clicchiamo col tasto destro su main nel pannello di Git Graph e scegliamo Checkout Branch:
La barra di stato mostra:
...e in explorer il nuovo file è scomparso:
Facciamo delle modifiche a README:
Procediamo quindi a un commit. La situazione è questa:
Graph mostra che main è avanzato di un passo (Modifica urgente a Readme) mentre contatti è rimasto dove lo avevamo lasciato.
Proseguire il lavoro sulla nuova feature
Proviamo a tornare con un checkout a contatti, modifichiamolo ancora e facciamo un ulteriore commit:
Nota che i colori sono cambiati: il ramo sul quale stai lavorando è azzurro, mentre main è segnato in fucsia.
Incorporare le modifiche in main
Ora che abbiamo terminato lo sviluppo della nuova feature contatti, vogliamo incorporarla nel ramo principale, in modo che possa essere messa in produzione.
Per prima cosa facciamo un checkout del ramo main:
A questo punto, su Graph, clicchiamo col tasto destro sul commit della versione definitiva dei contatti e scegliamo "Merge into current branch"(unisci al ramo corrente):
Alla richiesta di conferma procediamo creando anche un nuovo commit:
La situazione finale è questa: appare chiaro che le modifiche del ramo contatti sono state incorporate nel ramo principale:
Un po' di pulizia
A questo punto il ramo contatti non ci serve più, e se vogliamo possiamo anche eliminarlo cliccando col tasto destro e scegliendo Delete Branch:
Alla richiesta di conferma possiamo scegliere di eliminare il ramo anche dal repository remoto (GitHub):
Tutti i commit fatti rimangono a tua disposizione, nel caso dovessi andare a cercare delle modifiche fatte:
Il ramo contatti però non esiste più, così se un giorno volessi nuovamente lavorare sui contatti e riaprire un branch con lo stesso nome potresti farlo.
Workflow
Ecco come si procede normalmente:
Si mantiene il ramo master (main) per la versione di produzione: sarà quella che vedranno gli utenti.
Nel caso sia necessaria la correzione urgente di un bug si lavora direttamente sul master creando un hotfix (correzione a caldo).
Si mantiene un secondo ramo develop con la versione di sviluppo dell'applicazione: sarà quella che vedranno gli sviluppatori, e da questa partiranno per fare le loro modifiche.
Le feature vengono sviluppate in rami temporanei che poi vengono uniti al ramo develop.
Di tanto in tanto il ramo di sviluppo viene unito al master, e si ha il rilascio di una nuova versione dell'applicazione.
Contribuire a un progetto
Proporre modifiche
Importante: nomi dei file
Il server Linux su cui sono ospitati i siti veri e propri fa distinzione tra lettere maiuscole e minuscole nei nomi dei file. Per Windows invece maiuscole e minuscole sono indifferenti. Per evitare problemi conveniamo di denominare sempre i file delle immagini, ecc. con lettere solo minuscole.
Per i file contenenti i componenti di React usiamo invece sempre l'iniziale maiuscola come di consueto.
Preparativi
Rami
Il repository contiene vari branch (rami):
- main: ramo principale, qui vengono caricati gli aggiornamenti ai componenti
- donboscosandona, inoratorio, per: rami per il sito della scuola, dell'oratorio e della proposta estate
- $bar, $piscina, ecc.: sono i rami per i nostri clienti virtuali, tutti preceduti dal simbolo $
- cognome-sito-modifica: sono rami temporanei creati da chi contribuisce ai vari progetti
Clona il repository e apri il ramo sul quale devi fare modifiche:
Crea a partire da questo un nuovo ramo:
Denomina il ramo in questo modo:cognome-sito-modifica
Esempio:
- Armando Solighetto...
- ...sul sito della gelateria...
- ...è incaricato di aggiornare il listino prezzi
Il nome del ramo potrebbe essere:
Passa al ramo appena creato:
Modifiche
Fai tutte le modifiche necessarie ai file.
Dopo aver controllato che sia tutto a posto, crea un commit:
Nota: puoi anche creare dei commit intermedi se lo desideri, mentre fai singole modifiche e non sei ancora pronto a inviare il lavoro finito.
Pull request
Quando sei pronto a inviare le modifiche apri una pull request:
Compila con attenzione la richiesta
E' importantissimo specificare con attenzione il ramo di destinazione (gelateria) sul quale le modifiche dovranno essere salvate.
Ora la tua richiesta sarà inviata al prof per l'approvazione:
Il messaggio "Branch Protection policy..." è normale e indica che la richiesta dovrà essere approvata.
Se il prof approverà la richiesta non dovrai più fare nulla, se invece ti scriverà chiedendo delle modifiche dovrai farle rimanendo sempre sul ramo e sulla pull request che hai creato e aggiungendo un ulteriore commit.
Lavora liberamente nel tuo repository.
Nota che quando modifichi un file, le righe modificate o aggiunte vengono evidenziate accanto ai numeri di riga:
Se clicchi su questi evidenziatori ti compare un dettaglio delle modifiche fatte:
Nell'explorer vengono evidenziati i file modificati (M) o creati (U):
Nella sezione Source Control avrai la possibilità di annullare tutte le modifiche fatte o quelle fatte a un singolo file premendo l'icona della freccia che torna indietro (Revert):
Cliccando col tasto destro sul nome di un file e scegliendo Open Changes puoi vedere il confronto tra la versione iniziale del file e quella con le modifiche fatte:
Da Git Graph puoi vedere la situazione attuale del repository:
Qui vediamo 2 modifiche che per ora non sono state salvate nel sistema di versioning di Git (Uncommitted Changes) che provengono dal ramo main (principale) del repository.
Nota che quando modifichi un file, le righe modificate o aggiunte vengono evidenziate accanto ai numeri di riga:
Se clicchi su questi evidenziatori ti compare un dettaglio delle modifiche fatte:
Nell'explorer vengono evidenziati i file modificati (M) o creati (U):
Nella sezione Source Control avrai la possibilità di annullare tutte le modifiche fatte o quelle fatte a un singolo file premendo l'icona della freccia che torna indietro (Revert):
Cliccando col tasto destro sul nome di un file e scegliendo Open Changes puoi vedere il confronto tra la versione iniziale del file e quella con le modifiche fatte:
Da Git Graph puoi vedere la situazione attuale del repository:
Qui vediamo 2 modifiche che per ora non sono state salvate nel sistema di versioning di Git (Uncommitted Changes) che provengono dal ramo main (principale) del repository.
Ogni tanto nel corso del tuo sviluppo, puoi salvare la situazione delle modifiche fatte creando un "Commit".
È una buona pratica fare un commit ogni volta che hai terminato di aggiornare una certa parte del tuo sito o della tua applicazione: in questo se ti accorgerai di aver commesso degli errori potrai tornare a una versione precedente. Nei progetti condivisi questo è utile anche per vedere quali modifiche sono state fatte da altri sviluppatori.
Per fare un commit vai nel pannello Source Control e scegli un commento per il commit: il commento dev'essere qualcosa di breve che ti faccia capire in sintesi di che modifiche si tratta:
Premi poi il pulsante Commit: vedrai che la lista dei file modificati scompare da Source Control, perché adesso le modifiche sono state incorporate nella versione corrente del repository.
Nota anche che nella parte inferiore è comparso il numero 1 vicino alla freccia dei commit non sincronizzati: questo ti informa che il commit è presente nel tuo computer locale, ma non è stato ancora sincronizzato col repository remoto su GitHub.
La situazione su Git Graph è questa:
A differenza di prima ora le modifiche hanno una descrizione, e sulla destra puoi vedere l'autore del commit e il codice di hash che lo identifica (ad es. ac7091de).
È una buona pratica fare un commit ogni volta che hai terminato di aggiornare una certa parte del tuo sito o della tua applicazione: in questo se ti accorgerai di aver commesso degli errori potrai tornare a una versione precedente. Nei progetti condivisi questo è utile anche per vedere quali modifiche sono state fatte da altri sviluppatori.
Per fare un commit vai nel pannello Source Control e scegli un commento per il commit: il commento dev'essere qualcosa di breve che ti faccia capire in sintesi di che modifiche si tratta:
Premi poi il pulsante Commit: vedrai che la lista dei file modificati scompare da Source Control, perché adesso le modifiche sono state incorporate nella versione corrente del repository.
Nota anche che nella parte inferiore è comparso il numero 1 vicino alla freccia dei commit non sincronizzati: questo ti informa che il commit è presente nel tuo computer locale, ma non è stato ancora sincronizzato col repository remoto su GitHub.
La situazione su Git Graph è questa:
A differenza di prima ora le modifiche hanno una descrizione, e sulla destra puoi vedere l'autore del commit e il codice di hash che lo identifica (ad es. ac7091de).
Push
Procedi pure con la sincronizzazione del commit con GitHub. Questa operazione viene detta "Push".
Puoi farla sia premendo l'icona sulla barra distato:
Dopo aver fatto la sincronizzazione la situazione mostrata da Git Graph è questa:
Qui vediamo che (origin/main), cioè il repository principale su GitHub, si è allineato con il nostro repository locale (main).
Andando a curiosare sul sito di GitHub vedrai che le modifiche sono state riportate effettivamente anche lì:
Puoi farla sia premendo l'icona sulla barra distato:
Dopo aver fatto la sincronizzazione la situazione mostrata da Git Graph è questa:
Qui vediamo che (origin/main), cioè il repository principale su GitHub, si è allineato con il nostro repository locale (main).
Andando a curiosare sul sito di GitHub vedrai che le modifiche sono state riportate effettivamente anche lì:
Nei progetti condivisi questa funzionalità è molto utile, perché ti permette di vedere direttamente dal sito su quali file stanno lavorando gli altri sviluppatori.
Pull
L'operazione di Push invia le modifiche al cloud di GitHub, ma premendo il pulsante di sincronizzazione viene contestualmente avviata anche un'operazione di Pull, che va a scaricare eventuali aggiornamenti trovati sul repository (utile ad esempio se qualche altro sviluppatore nel frattempo ha modificato dei file).
Merge
Se per caso le tue modifiche dovessero andare in conflitto con quelle fatte da qualcun altro sullo stesso file, viene avviata un'operazione di merge (fusione) delle modifiche: Git prova a incorporare le modifiche di entrambi, e nel caso non ci riesca (quando ad esempio entrambi hanno modificato la stessa riga) ti chiede un aiuto, e devi scegliere se tenere le tue modifiche o quelle dell'altro sviluppatore, procedendo anche a un nuovo commit che risolve la situazione.
Branch
Quando si lavora a una nuova funzionalità, o alla correzione di un bug, è buona regola aprire un nuovo ramo (branch):
È facile comprendere che si tratta di un ramo importante, che non dovrà contenere modifiche fatte a metà, ma solo cose definitive.
Mentre gli utenti hanno accesso a questa versione dell'applicazione, gli sviluppatori devono poter lavorare a delle modifiche (bugfix = correzione di bug / feature = nuove funzionalità) ma queste modifiche possono richiedere giorni, lo sviluppatore può iniziare con un'idea e poi rendersi conto di aver commesso degli errori, ripararli e così via.
Solo quando sarà soddisfatto caricherà le modifiche anche nel ramo principale.
Vediamo come si fa in pratica.
Creare un nuovo ramo
Nella barra di stato compare il nome del ramo sul quale stai attualmente lavorando (main):
Premi su main e scegli "Create new branch":
Scegli per il nuovo ramo un nome che ti aiuti ad identificarlo. Per esempio supponiamo di voler lavorare a una nuova pagina dei contatti:
Fatto questo la barra di stato ti mostra che stai lavorando sul ramo "contatti":
e Code ti da la possibilità di pubblicare il ramo anche su GitHub:
Git Graph mostra questa situazione:
Proviamo allora a creare questo nuovo file:
La situazione è questa:
E dopo un commit:
Passare a un altro ramo
Supponiamo di dover tornare al ramo main per sistemare una cosa urgente, mettendo per un po' da parte la nuova funzionalità dei contatti.
Per farlo clicchiamo col tasto destro su main nel pannello di Git Graph e scegliamo Checkout Branch:
La barra di stato mostra:
...e in explorer il nuovo file è scomparso:
Facciamo delle modifiche a README:
Procediamo quindi a un commit. La situazione è questa:
Graph mostra che main è avanzato di un passo (Modifica urgente a Readme) mentre contatti è rimasto dove lo avevamo lasciato.
Proseguire il lavoro sulla nuova feature
Proviamo a tornare con un checkout a contatti, modifichiamolo ancora e facciamo un ulteriore commit:
Nota che i colori sono cambiati: il ramo sul quale stai lavorando è azzurro, mentre main è segnato in fucsia.
Incorporare le modifiche in main
Ora che abbiamo terminato lo sviluppo della nuova feature contatti, vogliamo incorporarla nel ramo principale, in modo che possa essere messa in produzione.
Per prima cosa facciamo un checkout del ramo main:
A questo punto, su Graph, clicchiamo col tasto destro sul commit della versione definitiva dei contatti e scegliamo "Merge into current branch"(unisci al ramo corrente):
Alla richiesta di conferma procediamo creando anche un nuovo commit:
La situazione finale è questa: appare chiaro che le modifiche del ramo contatti sono state incorporate nel ramo principale:
Un po' di pulizia
A questo punto il ramo contatti non ci serve più, e se vogliamo possiamo anche eliminarlo cliccando col tasto destro e scegliendo Delete Branch:
Alla richiesta di conferma possiamo scegliere di eliminare il ramo anche dal repository remoto (GitHub):
Tutti i commit fatti rimangono a tua disposizione, nel caso dovessi andare a cercare delle modifiche fatte:
Il ramo contatti però non esiste più, così se un giorno volessi nuovamente lavorare sui contatti e riaprire un branch con lo stesso nome potresti farlo.
Workflow
Ecco come si procede normalmente:
Si mantiene il ramo master (main) per la versione di produzione: sarà quella che vedranno gli utenti.
Nel caso sia necessaria la correzione urgente di un bug si lavora direttamente sul master creando un hotfix (correzione a caldo).
Si mantiene un secondo ramo develop con la versione di sviluppo dell'applicazione: sarà quella che vedranno gli sviluppatori, e da questa partiranno per fare le loro modifiche.
Le feature vengono sviluppate in rami temporanei che poi vengono uniti al ramo develop.
Di tanto in tanto il ramo di sviluppo viene unito al master, e si ha il rilascio di una nuova versione dell'applicazione.
Contribuire a un progetto
Proporre modifiche
Importante: nomi dei file
Il server Linux su cui sono ospitati i siti veri e propri fa distinzione tra lettere maiuscole e minuscole nei nomi dei file. Per Windows invece maiuscole e minuscole sono indifferenti. Per evitare problemi conveniamo di denominare sempre i file delle immagini, ecc. con lettere solo minuscole.
Per i file contenenti i componenti di React usiamo invece sempre l'iniziale maiuscola come di consueto.
Preparativi
Rami
Il repository contiene vari branch (rami):
- main: ramo principale, qui vengono caricati gli aggiornamenti ai componenti
- donboscosandona, inoratorio, per: rami per il sito della scuola, dell'oratorio e della proposta estate
- $bar, $piscina, ecc.: sono i rami per i nostri clienti virtuali, tutti preceduti dal simbolo $
- cognome-sito-modifica: sono rami temporanei creati da chi contribuisce ai vari progetti
Clona il repository e apri il ramo sul quale devi fare modifiche:
Crea a partire da questo un nuovo ramo:
Denomina il ramo in questo modo:cognome-sito-modifica
Esempio:
- Armando Solighetto...
- ...sul sito della gelateria...
- ...è incaricato di aggiornare il listino prezzi
Il nome del ramo potrebbe essere:
Passa al ramo appena creato:
Modifiche
Fai tutte le modifiche necessarie ai file.
Dopo aver controllato che sia tutto a posto, crea un commit:
Nota: puoi anche creare dei commit intermedi se lo desideri, mentre fai singole modifiche e non sei ancora pronto a inviare il lavoro finito.
Pull request
Quando sei pronto a inviare le modifiche apri una pull request:
Compila con attenzione la richiesta
E' importantissimo specificare con attenzione il ramo di destinazione (gelateria) sul quale le modifiche dovranno essere salvate.
Ora la tua richiesta sarà inviata al prof per l'approvazione:
Il messaggio "Branch Protection policy..." è normale e indica che la richiesta dovrà essere approvata.
Se il prof approverà la richiesta non dovrai più fare nulla, se invece ti scriverà chiedendo delle modifiche dovrai farle rimanendo sempre sul ramo e sulla pull request che hai creato e aggiungendo un ulteriore commit.
Quando si lavora a una nuova funzionalità, o alla correzione di un bug, è buona regola aprire un nuovo ramo (branch):
È facile comprendere che si tratta di un ramo importante, che non dovrà contenere modifiche fatte a metà, ma solo cose definitive.
Mentre gli utenti hanno accesso a questa versione dell'applicazione, gli sviluppatori devono poter lavorare a delle modifiche (bugfix = correzione di bug / feature = nuove funzionalità) ma queste modifiche possono richiedere giorni, lo sviluppatore può iniziare con un'idea e poi rendersi conto di aver commesso degli errori, ripararli e così via.
Solo quando sarà soddisfatto caricherà le modifiche anche nel ramo principale.
Vediamo come si fa in pratica.
È facile comprendere che si tratta di un ramo importante, che non dovrà contenere modifiche fatte a metà, ma solo cose definitive.
Mentre gli utenti hanno accesso a questa versione dell'applicazione, gli sviluppatori devono poter lavorare a delle modifiche (bugfix = correzione di bug / feature = nuove funzionalità) ma queste modifiche possono richiedere giorni, lo sviluppatore può iniziare con un'idea e poi rendersi conto di aver commesso degli errori, ripararli e così via.
Solo quando sarà soddisfatto caricherà le modifiche anche nel ramo principale.
Vediamo come si fa in pratica.
Creare un nuovo ramo
Nella barra di stato compare il nome del ramo sul quale stai attualmente lavorando (main):
Premi su main e scegli "Create new branch":
Scegli per il nuovo ramo un nome che ti aiuti ad identificarlo. Per esempio supponiamo di voler lavorare a una nuova pagina dei contatti:
Fatto questo la barra di stato ti mostra che stai lavorando sul ramo "contatti":
e Code ti da la possibilità di pubblicare il ramo anche su GitHub:
Git Graph mostra questa situazione:
Proviamo allora a creare questo nuovo file:
La situazione è questa:
E dopo un commit:
Premi su main e scegli "Create new branch":
Scegli per il nuovo ramo un nome che ti aiuti ad identificarlo. Per esempio supponiamo di voler lavorare a una nuova pagina dei contatti:
Fatto questo la barra di stato ti mostra che stai lavorando sul ramo "contatti":
e Code ti da la possibilità di pubblicare il ramo anche su GitHub:
Git Graph mostra questa situazione:
Proviamo allora a creare questo nuovo file:
La situazione è questa:
E dopo un commit:
Passare a un altro ramo
Supponiamo di dover tornare al ramo main per sistemare una cosa urgente, mettendo per un po' da parte la nuova funzionalità dei contatti.
Per farlo clicchiamo col tasto destro su main nel pannello di Git Graph e scegliamo Checkout Branch:
La barra di stato mostra:
...e in explorer il nuovo file è scomparso:
Facciamo delle modifiche a README:
Procediamo quindi a un commit. La situazione è questa:
Graph mostra che main è avanzato di un passo (Modifica urgente a Readme) mentre contatti è rimasto dove lo avevamo lasciato.
Per farlo clicchiamo col tasto destro su main nel pannello di Git Graph e scegliamo Checkout Branch:
La barra di stato mostra:
...e in explorer il nuovo file è scomparso:
Facciamo delle modifiche a README:
Procediamo quindi a un commit. La situazione è questa:
Graph mostra che main è avanzato di un passo (Modifica urgente a Readme) mentre contatti è rimasto dove lo avevamo lasciato.
Proseguire il lavoro sulla nuova feature
Proviamo a tornare con un checkout a contatti, modifichiamolo ancora e facciamo un ulteriore commit:
Nota che i colori sono cambiati: il ramo sul quale stai lavorando è azzurro, mentre main è segnato in fucsia.
Nota che i colori sono cambiati: il ramo sul quale stai lavorando è azzurro, mentre main è segnato in fucsia.
Incorporare le modifiche in main
Ora che abbiamo terminato lo sviluppo della nuova feature contatti, vogliamo incorporarla nel ramo principale, in modo che possa essere messa in produzione.
Per prima cosa facciamo un checkout del ramo main:
A questo punto, su Graph, clicchiamo col tasto destro sul commit della versione definitiva dei contatti e scegliamo "Merge into current branch"(unisci al ramo corrente):
Alla richiesta di conferma procediamo creando anche un nuovo commit:
La situazione finale è questa: appare chiaro che le modifiche del ramo contatti sono state incorporate nel ramo principale:
Per prima cosa facciamo un checkout del ramo main:
A questo punto, su Graph, clicchiamo col tasto destro sul commit della versione definitiva dei contatti e scegliamo "Merge into current branch"(unisci al ramo corrente):
Alla richiesta di conferma procediamo creando anche un nuovo commit:
La situazione finale è questa: appare chiaro che le modifiche del ramo contatti sono state incorporate nel ramo principale:
Un po' di pulizia
A questo punto il ramo contatti non ci serve più, e se vogliamo possiamo anche eliminarlo cliccando col tasto destro e scegliendo Delete Branch:
Alla richiesta di conferma possiamo scegliere di eliminare il ramo anche dal repository remoto (GitHub):
Tutti i commit fatti rimangono a tua disposizione, nel caso dovessi andare a cercare delle modifiche fatte:
Il ramo contatti però non esiste più, così se un giorno volessi nuovamente lavorare sui contatti e riaprire un branch con lo stesso nome potresti farlo.
Alla richiesta di conferma possiamo scegliere di eliminare il ramo anche dal repository remoto (GitHub):
Tutti i commit fatti rimangono a tua disposizione, nel caso dovessi andare a cercare delle modifiche fatte:
Il ramo contatti però non esiste più, così se un giorno volessi nuovamente lavorare sui contatti e riaprire un branch con lo stesso nome potresti farlo.
Ecco come si procede normalmente:
Si mantiene il ramo master (main) per la versione di produzione: sarà quella che vedranno gli utenti.
Nel caso sia necessaria la correzione urgente di un bug si lavora direttamente sul master creando un hotfix (correzione a caldo).
Si mantiene un secondo ramo develop con la versione di sviluppo dell'applicazione: sarà quella che vedranno gli sviluppatori, e da questa partiranno per fare le loro modifiche.
Le feature vengono sviluppate in rami temporanei che poi vengono uniti al ramo develop.
Di tanto in tanto il ramo di sviluppo viene unito al master, e si ha il rilascio di una nuova versione dell'applicazione.
Si mantiene il ramo master (main) per la versione di produzione: sarà quella che vedranno gli utenti.
Nel caso sia necessaria la correzione urgente di un bug si lavora direttamente sul master creando un hotfix (correzione a caldo).
Si mantiene un secondo ramo develop con la versione di sviluppo dell'applicazione: sarà quella che vedranno gli sviluppatori, e da questa partiranno per fare le loro modifiche.
Le feature vengono sviluppate in rami temporanei che poi vengono uniti al ramo develop.
Di tanto in tanto il ramo di sviluppo viene unito al master, e si ha il rilascio di una nuova versione dell'applicazione.
Contribuire a un progetto
Proporre modifiche
Importante: nomi dei file
Il server Linux su cui sono ospitati i siti veri e propri fa distinzione tra lettere maiuscole e minuscole nei nomi dei file. Per Windows invece maiuscole e minuscole sono indifferenti. Per evitare problemi conveniamo di denominare sempre i file delle immagini, ecc. con lettere solo minuscole.
Per i file contenenti i componenti di React usiamo invece sempre l'iniziale maiuscola come di consueto.
Preparativi
Rami
Il repository contiene vari branch (rami):
- main: ramo principale, qui vengono caricati gli aggiornamenti ai componenti
- donboscosandona, inoratorio, per: rami per il sito della scuola, dell'oratorio e della proposta estate
- $bar, $piscina, ecc.: sono i rami per i nostri clienti virtuali, tutti preceduti dal simbolo $
- cognome-sito-modifica: sono rami temporanei creati da chi contribuisce ai vari progetti
Clona il repository e apri il ramo sul quale devi fare modifiche:
Crea a partire da questo un nuovo ramo:
Denomina il ramo in questo modo:cognome-sito-modifica
Esempio:
- Armando Solighetto...
- ...sul sito della gelateria...
- ...è incaricato di aggiornare il listino prezzi
Il nome del ramo potrebbe essere:
Passa al ramo appena creato:
Modifiche
Fai tutte le modifiche necessarie ai file.
Dopo aver controllato che sia tutto a posto, crea un commit:
Nota: puoi anche creare dei commit intermedi se lo desideri, mentre fai singole modifiche e non sei ancora pronto a inviare il lavoro finito.
Pull request
Quando sei pronto a inviare le modifiche apri una pull request:
Compila con attenzione la richiesta
E' importantissimo specificare con attenzione il ramo di destinazione (gelateria) sul quale le modifiche dovranno essere salvate.
Ora la tua richiesta sarà inviata al prof per l'approvazione:
Il messaggio "Branch Protection policy..." è normale e indica che la richiesta dovrà essere approvata.
Se il prof approverà la richiesta non dovrai più fare nulla, se invece ti scriverà chiedendo delle modifiche dovrai farle rimanendo sempre sul ramo e sulla pull request che hai creato e aggiungendo un ulteriore commit.
Importante: nomi dei file
Il server Linux su cui sono ospitati i siti veri e propri fa distinzione tra lettere maiuscole e minuscole nei nomi dei file. Per Windows invece maiuscole e minuscole sono indifferenti. Per evitare problemi conveniamo di denominare sempre i file delle immagini, ecc. con lettere solo minuscole.
Per i file contenenti i componenti di React usiamo invece sempre l'iniziale maiuscola come di consueto.
Preparativi
Rami
Il repository contiene vari branch (rami):
- main: ramo principale, qui vengono caricati gli aggiornamenti ai componenti
- donboscosandona, inoratorio, per: rami per il sito della scuola, dell'oratorio e della proposta estate
- $bar, $piscina, ecc.: sono i rami per i nostri clienti virtuali, tutti preceduti dal simbolo $
- cognome-sito-modifica: sono rami temporanei creati da chi contribuisce ai vari progetti
Clona il repository e apri il ramo sul quale devi fare modifiche:
Crea a partire da questo un nuovo ramo:
Denomina il ramo in questo modo:
cognome-sito-modifica
Esempio:
- Armando Solighetto...
- ...sul sito della gelateria...
- ...è incaricato di aggiornare il listino prezzi
Il nome del ramo potrebbe essere:
Passa al ramo appena creato:
Passa al ramo appena creato:
Modifiche
Fai tutte le modifiche necessarie ai file.
Dopo aver controllato che sia tutto a posto, crea un commit:
Dopo aver controllato che sia tutto a posto, crea un commit:
Nota: puoi anche creare dei commit intermedi se lo desideri, mentre fai singole modifiche e non sei ancora pronto a inviare il lavoro finito.
Pull request
Quando sei pronto a inviare le modifiche apri una pull request:
Compila con attenzione la richiesta
E' importantissimo specificare con attenzione il ramo di destinazione (gelateria) sul quale le modifiche dovranno essere salvate.
Ora la tua richiesta sarà inviata al prof per l'approvazione:
Il messaggio "Branch Protection policy..." è normale e indica che la richiesta dovrà essere approvata.
Se il prof approverà la richiesta non dovrai più fare nulla, se invece ti scriverà chiedendo delle modifiche dovrai farle rimanendo sempre sul ramo e sulla pull request che hai creato e aggiungendo un ulteriore commit.