Git di base

Creazione di un nuovo progetto

Normalmente la cosa migliore è crearlo su github o gitlab ed esportarlo da lì, anche se si è già realizzata una parte o tutto il progetto. Una volta creato il nuovo progetto si può scaricare (clonare) e quindi iniziare a lavorare: dal sito trovare il link e da console digitare

git clone git://autore/nomedelprogetto.git

A questo punto è opportuno impostare il nome e l'email di lavoro. In locale e varrà solo per questo progetto:

cd nomedelprogetto
git config user.name "your name"
git config user.email "Questo indirizzo email è protetto dagli spambots. È necessario abilitare JavaScript per vederlo."

Oppure per tutti i progetti a livello globale (eventualmente alcuni progetti potranno essere impostati diversamente:

git config --global user.name "your name"
git config --global user.email "Questo indirizzo email è protetto dagli spambots. È necessario abilitare JavaScript per vederlo."

Ora, per non dover inserire ad ogni operazione di sincronizzazione le credenziali, è opportuno procedere con la creazione (se già non ne avete una) di una coppia di chiavi RSA:

ssh-keygen -t rsa -b 4096 -C "Questo indirizzo email è protetto dagli spambots. È necessario abilitare JavaScript per vederlo."

senza alcuna passphrase, o poi sarà richiesta ad ogni piè sospinto, quindi digitare invio fino alla conferma finale della generazione. Per vedere la tua nuova chiave, ispeziona la cartella

ls -la ~/.ssh

dovrebbe contenere il file id_rsa.pub, copia il contenuto su github o gitlab nell'apposita casella delle impostazioni personali (github, gitlab). A questo punto dovresti riuscire a sincronizzare il tuo progetto con il repository nel cloud senza inserire utente e password. Tieni presente che il trucco funziona se l'utente impostato su git in locale e su github/lab devono avere la stessa email.

Iniziare un nuovo progetto

git clone Questo indirizzo email è protetto dagli spambots. È necessario abilitare JavaScript per vederlo.:autore/nomedelprogetto.git
cd nomedelprogetto
touch README.md
git add README.md
git commit -m "add README"
git push -u origin master

Caricare un progetto già iniziato

cd nomedelprogetto
git init
git remote add origin Questo indirizzo email è protetto dagli spambots. È necessario abilitare JavaScript per vederlo.:autore/nomedelprogetto.git
git add .
git commit -m "Initial commit"
git push -u origin master

Caricare un progetto da un git già esistente ma su altro repository

cd nomedelprogetto
git remote rename origin old-origin
git remote add origin Questo indirizzo email è protetto dagli spambots. È necessario abilitare JavaScript per vederlo.:autore/nomedelprogetto.git
git push -u origin --all
git push -u origin --tags

Git normale amministrazione

Il ciclo di lavoro con git e un repository, se si osservano delle semplici regole, può essere indolore e rassicurante. Ma se non si rispettano e si fanno le cose a caso, può diventare un vero bagno di sangue. La procedura normale, se si lavora da soli o in gruppo sugli stessi file e cartelle, è banale: 1. lavori 2. aggiorni il git locale risolvendo i conflitti (pull + merge) 3. aggiorni il git remoto (add + commit + push) 4. torni al punto 1

In termini di comandi, la sequenza 2-3 è la seguente:

git status
git pull
git mergetool
git status
git add .
git commit -m 'comment'
git push

Se poi vuoi usare una GUI per fare lo stesso con comodità, il consiglio è sempre lo stesso: prima impara i comandi, poi puoi usare la GUI. Se non lo fai, ricordi il concetto del bagno di sangue? Ecco.

Il punto cruciale è la risoluzione dei conflitti. La maggior parte delle volte git fa lo sporco lavoro da solo e in silenzio. A volte però i conflitti sono generati da modifiche allo stesso file non compatibili, ovvero del tipo o una o l'altra ma non entrambe. In questi casi devi unire il codice a mano e git ti dice dove sono le differenze. Il mergetool a volte va configurato prima. Un file merger può tornare utile, come ad esempio è Meld. Applicazioni cone Eclipse, NetBeans e gli IDE in genere sono in grado di facilitare notevolmente il compito, come del resto anche le GUI per git stesso.

Oltre al flusso di lavoro grezzo descritto, ci sono almeno due e molto più validi modi di fare le cose, soprattutto quando il progetto consta di un team numeroso.

Feature branching workflow

Questo flusso di lavoro è piuttosto semplice da applicare: innanzitutto abbiamo il classico branch master che costituisce il filone principale di sviluppo; parallelamente ad esso si diramano n feature branch, ovvero rami di sviluppo focalizzati su funzionalità specifiche da aggiungere al progetto.

In pratica, nel momento in cui si comincia a lavorare su una nuova funzionalità, si crea un nuovo branch partendo da master:

git checkout master
git pull
git checkout -b nuova-funzionalita

I commit relativi alla nuova funzionalità avverranno sul branch corrispondente, che potrebbe risiedere solamente sul nostro repository locale, o che possiamo pushare nel repository centrale così da permettere ad altri componenti del team di collaborare con noi:

git push origin nuova-funzionalita

Nel momento in cui la nuova funzionalità è pronta per essere rilasciata in produzione, il feature branch può essere mergiato in master:

git checkout master
git pull
git merge --no-ff nuova-funzionalita
git push origin master

Solitamente viene utilizzata l’opzione --no-ff per il merge così da creare esplicitamente un merge commit che rappresenti un “punto di giunzione” tra il feature branch e master che identifichi (anche visivamente) un nuovo rilascio in produzione (concetto che può essere rafforzato applicando anche un apposito tag).

Dopo il merge è buona norma eliminare il ramo di sviluppo relativo alla funzionalità completata (eventualmente, anche dal repository centrale):

git branch -d nuova-funzionalita
git push origin --delete nuova-funzionalita

Gitflow

Esiste un altro famoso workflow, molto diffuso anche in ambito open source, che può essere considerato un’evoluzione del feature branching, ma che definisce regole molto più precise e, per certi versi, stringenti sul ciclo di vita dei branch.

Questo flusso di lavoro è stato ideato da Vincent Driessen e descritto per la prima volta nel 2010, in un ormai celebre articolo del suo blog.

Gitflow è particolarmente adatto ad essere impiegato in team di sviluppo Agile (Scrum) con rapidi cicli di sviluppo e rilascio del software; inoltre si adatta perfettamente a sistemi di deployment automatizzato tipici della Continuous Delivery.

Lo sviluppo si muove lungo due “binari” fondamentali: il classico branch master e un secondo ramo definito development o per brevità dev. Il primo includerà i soli commit relativi ai rilasci in produzione, il secondo branch sarà invece quello da utilizzare per l’effettivo sviluppo del progetto.

In fase di setup del nostro repository procederemo quindi in questo modo:

git checkout master
git pull
bit checkout -b dev

Diversamente da quanto visto nel feature branching workflow, in questo caso i branch relativi a nuove funzionalità andranno creati a partire da dev:

git checkout -b nuova-funzionalita dev

… e in esso andranno mergiati una volta completato lo sviluppo della feature:

git checkout dev
git pull
git merge --no-ff nuova-funzionalita
git push origin dev

Quando il progetto ha raggiunto uno stato papabile per il rilascio in produzione, è il momento di creare un nuovo release branch.

Anche i branch di rilascio si diramano da dev e comunemente seguono la naming convention release-{versione}:

git checkout -b release-1.0 dev

Nel branch di rilascio si andranno a completare tutte le attività finali (e, possibilmente, di minore entità) necessarie alla distribuzione di una nuova versione del progetto. Al termine di queste attività, il branch potrà essere mergiato in master ed eventualmente taggato con un corrispondente codice di versione:

git checkout master
git merge --no-ff release-1.0
git tag 1.0

Le modifiche introdotte nel release branch andranno poi riportate anche in dev:

git checkout dev
git merge --no-ff release-1.0

Infine, Gitflow prevede anche un’ulteriore tipologia di branch: gli hotfix-branch. Questi rami si originano direttamente da master e vengono utilizzati per correggere problemi riscontrati nella versione rilasciata in produzione.

Nel caso, ad esempio, fosse stato riscontrato un bug nella versione 1.0 appena rilasciata, dovremmo agire in questo modo:

git checkout -b hotfix-1.0.1 master

Terminate le attività di fixing, il ramo andrà nuovamente a confluire in master generando una nuova versione “stabile”:

git checkout master
git merge --no-ff hotfix-1.0.1
git tag 1.0.1

Come i release branch, anche gli hotfix branch vanno mergiati anche in dev:

git checkout dev
git merge --no-ff hotfix-1.0.1

Nota Se un nuovo release branch è già stato creato prima della chiusura dell’hotfix branch, quest’ultimo potrà essere mergiato direttamente nella nuova release.

Tutti i rami derivati da master e dev vanno eliminati dai repository locali e da quello centrale una volta mergiati nei branch principali.

Fonte: davioooh