GIT – appunti per sviluppatori

GIT è un Version Control System (VCS).

Permette di organizzare il codice e di tenere sotto controllo le proprie versione del codice, soprattutto quando si lavora in team.

Cosa puoi fare con GIT:

• controllare le proprie linee del tuo codice
• coordinare il lavoro
• controllare chi cosa quando
• tornare indietro
• mantenere repository locali e remoti (un posto dove andranno immagazzinate le informazioni del nostro codice: data, commenti, ecc) esempio: github, bitbucket

Comandi base:

GIT INIT: per cominciare tutto, momento in cui viene creata la repository

GIT STATUS: panoramica sintetica sullo stato della nostra repository

GIT ADD: aggiungere i files che poi verranno aggiunti alla repository

GIT COMMIT: aggiungere concretamente i propri files

GIT PUSH: pushare il nostro codice in una remote repository

GIT PULL: prendere gli aggiornamenti di codice dalla remote repository

GIT CLONE: clonare un progetto che si può trovare online

Una volta installato git sul nostro sistema operativo, bisognerà quindi lanciate git init all’interno della dir del nostro progetto e configurare il nostro utente.

git config --local user.name "Dora"
git config --local user.email "[email protected]

git status
Illustra la situazione della nostro repository in quel momento. E’ importante, ed anche sufficiente, leggere i messaggi. Ad esempio, la seguente situazione ci spiega, che:
– stiamo lavorando sul branch ‘master’
– nessun commit fin’ora
– ci sono dei files non ancora aggiunti all’area di staging (è un’area intermedia tra la directory di lavoro e la directory del VCS). Nota bene: qualsiasi elemento unstaged, cioè qualunque file che sia stato creato o modificato senza essere stato passato come argomento a git add, non potrà essere committato.
– non è stato aggiunto nulla per il commit ma sono presenti file non tracciati

On branch master
No commit yet
Untracked files: ....
Nothing added to commit but untracked files present

Quindi, se vogliamo aggiungere files alla staging area, bisogna utilizzare il comando git add <nomedelfile>.
Oppure git add -A . per aggiungere tutti i files in un colpo solo.
Se invece volessimo toglierlo dall’area di straging, bisogna lanciare il comando git rm --cached <nomedelfile>.

git commit
Questo bellissimo comando cosa fa?
Prende tutti i files che sta guardando nell’area di staging, li racchiude in un pacchetto e le manda al HEAD, ma non ancora nel repository remoto.
Nota bene: se lanciamo il comando in questo modo, si aprirà il vim editor per permettere di aggiungere un messaggio al commit. Per evitare questo, basta usare l’opzione git commit -m "Mio messaggio"

L’immagine presa da https://rogerdudler.github.io/git-guide/index.it.html, illustra fantasticamente i concetti appena descritti:

La tua copia locale del repository è composta da tre “alberi” mantenuti da git. Il primo è la tua Directory di lavoro che contiene i files attuali. Il secondo è l’Index (staging area) che fa da spazio di transito per i files e per finire l’HEAD che punta all’ultimo commit fatto.
PS: la staging area, concretamente, è il file nascosto che vediamo all’interno della cartella .git 😉

git checkout <nomedelfile>

Questo comando rimuove gli ultimi cambiamenti effettuati su un file e ritorna all’ultimo commit, quindi sostituirà le modifiche alla nostra directory di lavoro con i contenuti presenti nell’HEAD.
I cambiamenti fatti ed aggiunti all’index, così come i nuovi files, verranno mantenuti.

branching

Se stai lavorando con diverse persone e c’è un lavoro che devi fare in particolare, ti puoi staccare da esso, creando un nuovo branch. Una sorta di ramo che si distingue dal principale. In questo modo, sarai più libero di testare il proprio lavoro.
Alla fine se il branch è ok, puoi fare il merge ed unirlo al branch principale, ovvero il branch master.

git checkout <nomedelbranch>
git checkout master
git merge <nomedelbranch>

git log

Mostra la storia dei vari commits, con la possibilità di tornare ad uno specifico commits (ordine cronologico DESC)

git reset <mode> <commit>

Ad esempio abbiamo tre commit su un progetto, in ordine: commitA, commitB, commitC e volessimo tornare alla commitB?
Vediamo i due tipi di reset più utilizzati: mixed (di default) e hard.
Con il mixed reset, torniamo indietro alla commitB (nel log vedremo solo commitA e commitB) lasciando invariati i files nella working directory, però in fase di stage c’è la versione B. L’IDE che utilizzate dovrebbe darvi qualche segnale, su ciascun file coinvolto, delle area diverse tra la working directory e la staging area. Alla fine, per riportare i cambiamenti del commit che abbiamo utilizzato per il reset, bisogna lanciare il comando git checkout <nomedelfile>.
Con il hard reset, viene fatto un reset vero e proprio, riportando il progetto come se fosse appena stato fatto il commitB. Tutte le modifiche nel commitB e C andranno perse.

Per collegare il nostro progetto al repository remoto, questi sono i comandi

git remote add origin <url>
git remote -v
git push -u origin master

git clone <url>
Comando utile a copiare progetti online.

git push

Tutte il nostro lavoro, una volta portato nell’HEAD attraverso i commit, è nella copia locale. Per inviare al repository in remoto, bisogna lanciare il push.

git pull

Serve per prendere i files dal repository remoto, commitati da qualche collega.
Se ad esempio, si prova a pushare su un file di cui un collega ha già provveduto al push, il server git rifiuta il push perchè il remote repository contiene lavoro che tu non hai localmente.
Di solito riesce a fare il merge in automatico, ma se abbiamo modificato il file nella stessa riga, restituisce errore. In questo caso, bisogna procedere con il merge.
Apriamo il file in questione nell’editor e vedremo una serie di simboli <<<<< >>>>>>, quindi bisognerà decidere manualmente cosa vogliamo lasciare, cancellare tutti i simboli e lanciare successivamente i seguenti comandi:

git add -A .
git commit -m "merge effettuato"
git push

Meglio fare piccoli e frequenti aggiornamenti

Documentazione

Se vuoi inserire la documentazione del progetto all’interno del progetto stesso, allora si possono creare dei semplici file Markdown e ‘versionarli’ con il codice del progetto stesso.
>> Per impostare il file Leggimi basterà creare un file di testo nella radice del repository e denominarlo README.md. Esso verrà considerato da GitHub come il file readme del progetto.
Cosa si consiglia di riportare nel file Readme:
– istruzioni per l’installazione
– configurazione
– eventuali dipendenze
– configurazione del database
– come eseguire i test
– istruzioni per l’implementazione

Se invece vuoi avere la documentazione su un repository separato che contiene solo quello, allora puoi utilizzare https://www.gitbook.com/ che fondamentalmente usa Markdown per creare una documentazione “navigabile”.
Inoltre, è possibile creare dal progetto su GitBook un repository su Github.