GIT & GITHUB

Git è un software per il version control dei progetti. Mediante semplici comandi, è possibile caricare i propri
elaborati su un server remoto, modificarlo ecc. In questo modo più persone possono collaborare allo
sviluppo di progetti ovunque essi si trovino. diventa possibile controllare lo sviluppo del software riga per
riga, per tutta la sua evoluzione
GitHub invece è una piattaforma che offre servizio di versioning tramite Git.

In generale, è possibile usare Git sia da riga di comando, che tramite interfaccia grafica. Viene altamente
consigliata la prima opzione, che di fatto non costituisce un’alternativa difficile.

INSTALLAZIONE
Per installare l'applicazione, basta andare sul sito ufficiale ​https://git-scm.com​ e scaricare la versione di Git
compatibile con il proprio sistema operativo.

Windows
Dopo aver scaricato la versione desiderata, cliccare sull’eseguibile e seguire le istruzioni. In particolare, ad
un certo punto, viene chiesta la tipologia di installazione voluta: è caldamente consigliata l’installazione
della versione che include la bash di Linux. In questo modo, diventa possibile usare i comandi Linux/Unix
pur usando Windows. Così facendo, si mantiene una certa uniformità e diventa più semplice seguire gli
eventuali tutorial o forum dedicati a Git e non dover adattare i comandi con quelli di Windows.
Per tutte le altre opzioni, lasciare quelle di default.

Mentre l’installazione continua, approfittarne per creare un account (se non lo si ha già) su github.com
(normale registrazione: username, email universitaria, password) e confermarlo una volta creato. Infine,
accedere con le credenziali.

Una volta terminata l’installazione del programma, lanciare la bash Git (non spuntare l’opzione che riguarda
le note sulla versione). Quello che si presenta è un terminale Unix-like che si posiziona in una cartella
predefinita (solitamente la home). Per muoverci all’interno del file system, avremo bisogno di
essenzialmente due comandi Unix:
- cd: cambia cartella su cui posizionarsi:
- cd nomeCartella: si posiziona nella cartella nomeCartella presente in quella corrente
- cd .. : torna indietro alla cartella soprastante
- ls: visualizza il contenuto della cartella in cui si è in quel momento.

Mediante l’uso di questi comandi, posizionarsi in una cartella nota preferita. Qui, verrà salvata la repository
che andremo a creare.

CREARE UNA REPOSITORY

Una repository è un grande contenitore che permette di organizzare un singolo progetto. Contiene cartelle,
file, immagini, video, dati vari, codice ecc, spesso accompagnati da un README o comunque da un file
che fornisce tutte le informazioni necessarie a far capire all’utente esterno in che cosa consiste il progetto.

Per crearla, tornare su Github. Cliccare sull’icona “+” in alto a destra (accanto al proprio username) e poi su
“New repository”. Dare un nome alla repository (ed eventualmente una descrizione nell’apposito spazio) e
spuntare l’opzione “Initialize this repository with a README”. È infatti altamente consigliato creare un file
del genere in cui mettere tutte le informazioni necessarie a spiegare il proprio progetto.

CONFIGURARE GIT
Ora, passiamo alla configurazione di Git. Di fatto, andremo ad impostare il nome utente e l’indirizzo e-mail,
in modo da mostrare a Git con quale account si vuole incapsulare le varie operazione.
La configurazione è assai semplice. Andare sulla bash di Git e digitare i comandi:
$ git config --global user.name "user"
$ git config --global user.email user@domain.com

PRIME OPERAZIONI SU GIT E GITHUB

Ci occupiamo quindi di creare una copia della nostra repository, sul nostro PC. Di fatto si tratta di una
clonazione di quella presente sul server (su Github).
Per fare ciò, copiamo l’indirizzo della repository: su Github, una volta dentro la repository, cliccare sul
bottone verde “Clone or download”. Scegliere in particolare “Clone with HTTPS” e copiare il link.

Fatto ciò, torniamo sulla bash e digitiamo il comando ​git clone linkRepository​, dove linkRepository
è il link che abbiamo copiato da Github. In questo modo, abbiamo creato una copia locale del progetto (per
verificare la sua presenza, usare il comando ​ls​).

Proviamo quindi a creare un file all’interno della repository locale. Possiamo farlo direttamente nella cartella
(senza l’uso della bash): creiamo un file txt in cui ci scriviamo qualcosa e poi salviamo.
Dalla bash, dovremo quindi aggiornare la repository remota, seguendo questi step:
- Aggiungiamo il file a git (operazione ancora in locale): ​git add [nomeFile] [-A] [--all]
- Committiamo (i salvataggi delle modifiche alla repository vengono chiamati commit) le modifiche:
git commit -m “commento alle modifiche apportate” [nomeFile] ​(nota: o​gni
volta che si fa il commit solitamente si associa un messaggio in cui si descrive quali modifiche sono
state apportate. In qualche modo permettono di ricostruire la storia degli aggiornamenti del progetto
e permettono a chi legge di capire quali e perché sono stati fatti determinati cambiamenti.​)
- Pushamo le modifiche (operazione remota): ​git push [u- origin master]​ (nota: la prima
volta, viene chiesto di accedere all’account Github).

Infine, in generale è utile e interessante verificare lo stato della repository tramite il comando ​git status​:
questo fornisce tutte quelle informazioni che riguardano la cartella di lavoro locale, come la lista dei file
modificati, i file committati ecc.

CREARE UN BRANCH
Fare un branching vuol dire permettere di lavorare su differenti versioni di una sola repository e
contemporaneamente.
Di default, una repository ha un unico branch detto master, considerato come il branch definitivo. Usare più
branch permette di sperimentare diverse modifiche prima di inserirle nella versione finale: in questo mondo,
diventa semplice tornare alla versione prima di cambiamenti.

Per creare un nuovo branch: ​git branch nomeBranch​. Questo comando crea una copia della
repository master (o comunque dalla diramazione corrente). Una volta creata la diramazione, per
continuare a fare le modifiche su questa, si usa ​git checkout nomeBranch​: da qui in avanti,
qualunque modifica non toccherà il branch master.

Per vedere invece quali sono tutte le diramazioni della repository, si usa il comando ​git branch​. Questo
restituisce la lista di branch attivi ed evidenzia quello corrente.

Se ad un certo punto ci accorgiamo che la diramazione è diventata tanto divergente da poter essere
considerata indipendente dal master, si fa un fork: in questo modo si va a creare due master di fatto
indipendenti tra di loro (comando: ​git fork​).

PULL REQUEST
Dopo aver lavorato su una diramazione, si può voler fare il merge delle modifiche in modo da integrarle nel
master. In particolare, si potrebbe voler sapere l’opinione degli altri membri del team.
Si procede quindi facendo ​git merge master ​(se si vuole fare il merge verso il master, altrimenti il
nome del ramo padre) e gestendo eventuali conflitti.

Su Github, ci si posiziona nella diramazione che si vuole integrare, clicchiamo sul bottone verde (quello con
due frecce che si guardano) che permette di vedere quello che è cambiato rispetto al master. Clicchiamo
poi su “Create pull request”/“Send pull request”. I membri del team riceveranno una notifica a riguardo e
potranno commentare le modifiche apportate e quando riterranno che è tutto conforme, potranno cliccare
su “Merge pull request”/”Confirm”.

Una volta fatto il merge, si può cancellare il branch .

GESTIONE DEI CONFLITTI

Quando si fanno dei push, ci si può incappare in alcuni conflitti ed inconsistenze dovute al fatto che nello
stesso punto, esistono due contenuti diversi. Poiché Git non è in grado di risolverli automaticamente,
diventa compito nostro andare a vedere manualmente conflitto per conflitto cosa cosa accettare cosa
scartare.

Quello che Git ci mostra per indicarci i conflitti è strutturato nel seguente modo:
<<<<<<<<<<<<<<< HEAD
//quello che abbiamo scritto noi
===============
//quello che è presente nel file sul server
>>>>>>>>>>>>>>>MASTER

FARE UNO STASH

Capita di trovarsi ad un certo punto in cui le cose sono in uno stato confusionario si vuole passare ad
un'altra ramificazione per lavorare per un po' a qualcosa di diverso, senza però committare qualcosa fatta a
metà, per poi tornare su questa in un secondo momento.

Per fare questo, si può ricorrere al comando ​git stash​. Questo, prende tutte le modifiche della cartella di
lavoro — cioè tutti i file tracciati che hai modificato e le modifiche assemblate — e le accantona in una pila
di modifiche incomplete che possono essere ripescate in qualsiasi momento.
Per vedere il contenuto della pila di modifiche, si può usare il comando ​git stash list​.

Quando poi si vuole riprendere a modificare il lavoro accantonato, si usa il comando ​git stash apply​.
Se si vuole recuperare un accantonamento specifico, basta aggiungere il nome dello stash (di solito
stash@{i}​, dove i è l’indice di ordinamento dell’i-esimo accantonamento). Se non si specifica il nome, Git
suppone che si riferisca all'ultimo.

Se poi si vuole annullare una modifica allo stash, si usa il comando ​git stash unapply​.

Capita, infine, di voler lavorare a quel pezzo di progetto parziale, ma in un’altra diramazione: può allora
essere utile usare il comando ​git stash branch nomeBranch​.

GIT WORKFLOW
Ciò che segue è un elenco di regole che è bene seguire quando si è in team:
● Ogni volta che si riprende con il progetto, fare un pull in modo da assicurarsi che la versione su cui
si sta per lavorare sia quella aggiornata.
 ● Dopo aver fatto le modifiche da fare, aggiungerle alla repository e fare commit. In particolare,
dedicare particolare attenzione nella stesura del messaggio che accompagnerà il commit: è infatti
fondamentale per permettere agli altri membri del team di capire cosa è stato cambiato e perchè.
● Ogni tot commit effettuati, fare push. Si può decidere di farlo anche a fine modifica (o a fine
giornata), l’importante è non dimenticarsene: in questo modo, se per qualche motivo la propria
macchina locale si guastasse, si avrebbe comunque il progetto e le sue modifiche sane e salve.

GITHUB DA ECLIPSE
Eclipse integra un plug-in per il versioning. Possiamo quindi rifare tutte le operazioni basilari direttamente
dall’IDE.
1. Prepariamo l’IDE con tutte le view necessarie ad un versioning più immediato.​ Andando su
Window/Show View/Other apriamo una finestra di dialogo da cui selezioniamo Git/Git Repositories,
Git Staging e Git Reflog. Rispettivamente queste view serviranno a creare/clonare/aggiungere
repository, a gestire i commit e push e a visualizzare i log di versioning.
2. Configuriamo Git. ​Dalla barra in alto scegliamo Window/Preferences: ci appare una finestra di
dialogo da cui selezioniamo Team/Git/Configuration. Nel pannello che ci compare, clicchiamo su
Add Entry per aggiungere le nostre credenziali di Github. In particolare nella finestra di dialogo che
si apre, inseriamo “user.name” in Key e lo username in Value. Clicchiamo su OK per confermare.
Rifacciamo ancora questa operazione e in particolare aggiungiamo “user.email” in Key e l’email in
Value. Una volta inseriti i dati, confermiamo il tutto e usciamo dalla finestra di dialogo iniziale.
3. Cloniamo la repository creata su Github​. Nella view aggiunta nel primo punto (Git Repositories),
clicchiamo su “Clone a git repository”. Viene aperta una finestra di dialogo in cui dovremo inserire
l’URL della repository. Copiamo nell’apposito spazio l’URL copiato inizialmente: Eclipse riconosce
automaticamente il protocollo usato e completa i restanti campi. Terminare con l'inserimento delle
credenziali di Github nella sezione “Authentication” e premere Next. Successivamente, viene
chiesto di selezionare i branche che si vuole clonare: li selezioniamo tutti e premiamo ancora Next.
Infine, viene chiesto di confermare (cambiare) il percorso in cui salvare la repository localmente, il
branch principale (solitamente è il master) e il nome remoto (solitamente è origin). Terminiamo il
tutto cliccando su Finish.
4. Proviamo a modificare il file che abbiamo aggiunto inizialmente.​ Notiamo che quando
salviamo, nella view Git Staging, viene accodato il file modificato nella sezione “Unstaged changes”
(quindi possiamo dire che questa schermata è di fatto una specie di ​git status​ sempre
chiamato). Qui vengono segnalati i cambiamenti non ancora committati, ovvero quei cambiamenti di
cui Git viene a conoscenza ma che non sono stati ancora aggiunti alla repository. Quindi,
trasciniamo il file che compare in Unstaged changes verso la sezione Staged changes: questa
operazione equivale al comando ​git add​. Prima di fare il commit e push, inseriamo un messaggio
esplicativo.
5. Impariamo a familiarizzare con la finestra di log​. La view Git Reflog che abbiamo aggiunto
prima, è molto utile per tenere monitorato lo stato del versioning. Infatti, quando selezioniamo una
repository, viene visualizzato un elenco di tutti i commit-push fatti da noi e dagli altri membri dei
team.
6. Creiamo un nuovo branch​. Andiamo nella view Git Repositories, selezioniamo
nomeRepository/Branches/Local e clicchiamo col destro il branch (se esiste, altrimenti di default
sarà il master) da cui vogliamo fare la diramazione e scegliamo “Create branch”. Siccome la
creazione del nuovo branch è avvenuta solo in locale, dobbiamo “pushare” questo ramo: clicchiamo
con il destro sul nome della repository e selezioniamo “Push branch ‘nomeBranch’”; si apre una
finestra di dialogo in cui, cliccando Next, ci viene chiesto di inserire le credenziali di Github.
Confermare alla fine.
7. Gestione dei conflitti.​ Eclipse mette a disposizione un tool che permette di mettere a confronto
riga per riga due file conflittuali e lascia all’utente la scelta di quale versione scegliere.