Userò questo breve tutorial per fare un ripassone di cos'è e come si usa Git da terminale.
Cos'è Git?
Git è il più popolare sistema di versionamento utilizzato nello sviluppo del software. Esso, considera i propri dati come una serie di istantanee (snapshot) di un filesystem. Ogni volta che si committa, o si salva lo stato di un progetto in Git, fondamentalmente lui fa un'immagine di tutti i file in quell'esatto momento, salvando un riferimento allo snapshot. Per essere efficiente, se alcuni file non sono cambiati, Git non li risalva, ma crea semplicemente un collegamento al file precedente già salvato.
Questa è una distinzione importante tra Git e praticamente tutti gli altri VCS. Git riconsidera quasi tutti gli aspetti del controllo di versione che la maggior parte degli altri sistemi ha copiato dalle generazioni precedenti. Questo rende Git più simile a un mini filesystem con a disposizione strumenti incredibilmente potenti che un semplice VCS.
La maggior parte delle operazioni in Git, necessitano solo di file e risorse locali per operare: Per esempio, per navigare la storia di un progetto, Git non ha bisogno di connettersi al server per scaricarla e mostrarla: la legge direttamente dal database locale. Questo significa che potete vedere la storia del progetto quasi istantaneamente. Se volete vedere le modifiche introdotte tra la versione corrente e la versione di un mese fa di un file, Git può accedere al file com'era e calcolare le differenze localmente, invece di dover richiedere ad un server remoto di farlo o di scaricare dal server remoto una versione precedente del file, per poi farlo in locale.
Qualsiasi cosa in Git è controllata, tramite checksum, prima di essere salvata ed è referenziata da esso. Questo significa che è impossibile cambiare il contenuto di qualsiasi file o directory senza che Git lo sappia. Questa è una funzionalità interna di basso livello di Git ed è intrinseco della sua filosofia. Non può capitare che delle informazioni in transito si perdano o che un file si corrompa senza che Git non sia in grado di accorgersene.
Quasi tutte le azioni in Git aggiungono dati al database di Git. È piuttosto difficile fare qualcosa che non sia annullabile o che cancelli i dati in una qualche maniera. Questo rende piaceole l'uso di Git perché sappiamo che possiamo sperimentare senza il pericolo di causare danni gravi.
Cosa sono i tre stati di Git?
I file in Git possono essere in tre stati: committed (committati), modified(modificati) e staged (in stage). Committato significa che il file è al sicuro nel database locale. Modificato significa che il file è stato modificato, ma non è ancora stato committato nel database. In stage significa che si è contrassegnato un file, modificato nella versione corrente, perché venga inserito nello snapshot alla prossima commit (cioè viene eseguito il comando add sul file).
La directory di Git (HEAD) è dove vengono salvati i metadati e il database degli oggetti del progetto. Questa è la parte più importante di Git, ed è ciò che viene copiato quando si clona un repository.
La directory di lavoro (Working directory) è il checkout di una versione specifica del progetto. Questi file vengono estratti dal database compresso nella directory di Git, e salvati sul disco per essere usati o modificati. Quindi è l'insieme dei file effettivi del progetto.
L'area di stage (Index) E' l'insieme dei file aggiunti con il comando add, messi in sosta e pronti per il prossimo commit.
Il workflow di base in Git funziona modificando i file nella working directory. Una volta terminate le modifiche vengono aggiunte nella stage area ed infine committate, finendo nell'HEAD.
Quindi:
- File modificati -> Working directory
- File added -> Index
- File committed -> HEAD
- File pushed -> Online repository
I comandi base
- git init Crea un repository Git
- git clone /path/to/repository Crea una working directory clonando un repository
- git add <filename> (o git add * per tutti i file del repo) Aggiunge i file selezionati alla stage area (index) per prepararli alla commit
- git commit -m "Commit message" committa i file all'HEAD, ma solo localmente
- git push origin master Invia i cambiamenti appartenenti all'HEAD al repository online (cambiare master col branch sul quale si vuole psuhare)
- git remote add origin <server> Da eseguire se non è stato clonato precedentemente un repository ma si vuole connettere un repo offline a quello online
I branches (rami) sono utilizzati per sviluppare features isolate le une dalle altre. Infatti, il branch master è il branch default quando si crea un nuovo repository. Si usano altri branche per sviluppare tali features e unire (merge) il codice risultate al branch master una volta terminate.
- git checkout -b feature_x Crea un nuovo branch chiamato feature_x e cambia la working directory per usarla
- git checkout master Cambia la working directory nuovamente sulla master
- git branch -d feature_x Elimina il branch feature_x
- git push origin <branch> Push il branch selezionato
- git pull Aggiorna il repository locale agli ultimi commit
- git merge <branch> Unisce le modifiche del <branch> al branch attivo localmente
- git add <filename> Siccome il merge non sempre "fila liscio" ma è possibile il presentarsi di uno o più conflitti, spetta all'utente che lavora sul repository locale il fixing di tali conflitti, che verranno aggiunti con add e comittati nuovamente
- git diff <source_branch> <tatget_branch> Visualizza le differenze nel codice sorgente tra due branch
- git tag 1.0.0 1b2e1d63ff É buona norma taggare le release di software con dei tag. Nell'esempio viene creato il tag per il software con versione 1.0.0 legandolo ai primi 10 caratteri del commit legato alla release
- git log Viene visualizzata tutta la storia loggata di un repository (ed è da qua che si possono prendere i primi 10 caratteri dell'id di un commit) per esempio:
- git log --author=danilo Visulizza tutti i commit di un certo autore
- git log --pretty=oneline Visualizza tutti i commit su una singola riga
- git log --graph --oneline --decorate --all Visualizza i commit in modo molto pratico
- git log --name-status Visualizza i file che sono stati cambiati
- git log --help Visualizza tutti i parametri possibili col comando git log
Sostituire le modifiche locali
- git checkout --<filename> Nel caso in cui si sia fatto un errore, il comando sostituisce il file target presente nella working directory con la versione presente nell'HEAD. Tuttavia, i file già aggiunti nell'Index saranno mantenuti (quindi andrà effettuato un nuovo add)
- git fetch origin e git reset --hard origin/master Con questi due comandi vengono eliminati tutti i cambiamenti e i commit locali, scaricata l'ultima versione presente online del repository. Infine localmente viene puntata quest'ultima.
Le informazioni presentate in questo articolo sono state raccolte dai siti web:
- https://git-scm.com/book/it/v1/Per-Iniziare-Basi-di-Git
- http://rogerdudler.github.io/git-guide/