Saturday, March 17, 2018

Introduzione a Git

1. Introduzione


Git e' un sistema di version control (http://git-scm.org). Lo scopo di Git e' quello di tener traccia di tutti i cambiamenti effettuati all'interno di un progetto software in modo da assicurare sempre una versione di backup delle versioni precedenti. In questo modo, se qualcosa va storto, e' possibile invertire le modifiche e ripristinare il precedente stato funzionante del software.
A differenza degli altri sistemi di versionamento, quasi tutte le operazioni in Git non hanno bisogno di una connessione internet, perché sono operazioni che avvengono su disco locale. Git salva lo storico completo del progetto direttamente su disco locale e recuperare una vecchia versione di un file dalla history é una operazione istantanea. Anche le commit avvengono sul database locale
Git vs GitHub

Git e GitHub sono due cose diverse: GitHub e' un servizio online basato su Git, ma non e' indispensabile per usare Git e creare un repository. GitHub permette di hostare online un repository creato con Git e condividerlo con altri sviluppatori.
L'hosting pubblico su GitHub e' gratuito, l'hosting privato e' a pagamento. Per questo motivo gli sviluppatori usano altri servizi online per condividere repository Git, come GitLab.com e bitbucket.org.
Le aree di lavoro di Git

Git e' composto da quattro aree di lavoro:

Il luogo dove lo sviluppatore crea e modifica il codice del progetto e' rappresentato dalla working directory di Git, che contiene i file che andranno a costituire il repository Git.
Per creare la cartella di progetto ed inizializzare un nuovo repository Git, lancio il comando:
 
 git init myproject
Lo sviluppatore modifica il file nella working directory: lo sviluppatore effettua n modifiche al file. Dopo n tentativi, la versione n-ima compila e/o produce il risultato aspettato, per cui lo sviluppatore sposta il file in Staging.
Per spostare un file dalla working directory allo Staging si lancia il comando git add:
 git add <filepath>
Il comando git add non modifica in modo permanente il repository, ma specifica solo che il file parteciperá alla prossima commit.
Si puó utilizzare il comando git add per piú obbiettivi: incominciare a fare tracking di un file, aggiungere un file alla Staging Area e marcare i conflitti di merging come risolti.
Committare i file nel repository locale

Lo sviluppatore ha modificato alcuni file, i file di cui e' soddisfatto delle modifiche apportate si trovano nella Staging area, i file che richiedono ancora delle modifiche si trovano nella working directory. Siccome lo sviluppatore ha terminato la sessione di lavoro, vuole registrare uno snapshot del progetto e per fare cio' lo sviluppatore sposta i file dallo staging al repository.
Per committare tutti i file che si trovano nella Staging Area, si lancia il comando commit:
 git commit
Supponiamo che lo sviluppatore stia modificando uno staged file nella working directory, non vuole fare il commit del file perche' non ha ancora finito di lavorare sul file, ma vuole cambiare branches per lavorare su qualcos'altro. A questo punto, se lo sviluppatore non vuole salvare il lavoro incompleto nel repository, puo' salvare lo stato della Working Directory nello Stashing. In futuro lo sviluppatore puo' ripristinare lo stato della Working Directory dallo Stashing.
Per spostare i files dalla Working Directory allo Stashing uso il comando:
 git stash 
Per spostare i files dallo Stashing alla Working Directory uso il comando:
 git stash pop
Il workflow di Git

Gli stati di un file: committed, modified, staged

Un file nuovo, appena creato, per Git si trova nello stato untraked. Quando si sposta il file nella Staging area con git add, il file si trova nello stato staged. Quando si committa il file nel database, il file si trova nello stato committed. Se il file si trova nello stato staged o committed e viene editato, Git segnala che esiste una copia del file nel working tree nello stato modified.

2. Comandi Base di Git con esempio step-by-step


Vediamo come creare di un nuovo local repository Git, partendo da zero.
 cd  progetto-con-git/
 git init
Vediamo cosa ha fatto il comando git init, lanciando il comando ls: Git ha creato la cartella di progetto di nome progetto-con-git. Se mi sposto all'interno della cartella di progetto e lancio il comando ls -la, vedo la cartella di sistema di nome .git, che contiene i file che controllano le versioni storiche dei file di progetto, lo snapshots di documenti, immagini, sorgenti, etc.
Creo di un nuovo file chiamato my-file.txt, usando l'editor di testo nano.
 cd progetto-con-git
 nano my-file.txt 
Per vedere lo stato del working tree:
 git status
Si puo' leggere che sono sul ramo master, git segnala il file appena creato come untraked.

Il file e' pronto, per cui lo invio alla staging area (anche detta index):
 
 git add my-file.txt
Lancio ancora git status per vedere lo stato della working directory. Si puo' leggere che sono sul ramo master, il nome del file non e' piu' rosso ma verde e non ci sono commit ancora.
Inoltre, git suggerisce di usare il comando "git rm --cached <file>..." per rimuovere il file appena aggiunto dalla Staging area. Si provi ad usare il comando git rm per rimuovere il file dalla staging area.

Una volta copiato il file nella staging area, proviamo a modificare lo stesso file nella working directory. Per cui apriamo il file con l'editor di testo, lo modifichiamo e lo salviamo di nuovo. Lancio il comando git status e vedo che nello staging area c'é ancora il my-file.txt pronto per il commit, ma nel working tree c'é di nuovo my-file.txt nello stato modified pronto per essere aggiunto alla staging area per aggiornare la prossima commit.

Quindi, eseguo di nuovo git add . per avere tutte le modifiche pronte nella staging area.

Per committare le modifiche, uso il comando:
 git commit
Il comando apre l'editor di testo preferito allo scopo di inserire il messaggio relativo a quel commit. Posso decommentare la riga "# Initial commit" ed inserire un mio messaggio sulla prima riga.
Ogni volta che si fa un commit in Git, quel commit ha un commento ed un codice: il commento e' il messaggio che si aggiunge al commit e commenta le modifiche fatte, il codice e' autogenerato da Git. Il codice del commit serve nel caso in cui si vuole tornare indietro e ripristinare lo stato del progetto al momento del commit con uno specifico commento.
Eseguire git commit con flag -m
Se eseguo di nuovo git status, appare il messaggio: "nothing to commit, working tree clean", che vuol dire che non ci sono modifiche da committare.
Poi, creo un altro file di nome "second-file.txt", lo aggiungo alla staging area e infine faccio la commit. Questa volta lancio il comando commit con il parametro -m, per evitare di inserire il messaggio con l'editor di testo .
 
 git commit -m 'added second-file.txt'
Per vedere lo storico delle modifiche in Git posso usare il comando:
 
 git log

Che mosta tutte le commit effettuate nel repository corrente con rispettivo codice e nome.

No comments :

Post a Comment