In questo post viene presentato un tipico workflow per la gestione di un progetto tramite il software di controllo di versione distribuito git.

La branch master verrà utilizzata per mantenere una versione stabile del software, la branch develop invece verrà utilizzata per lo sviluppo di nuove funzionalità. La branch develop è chiamata long term branch.

Creiamo un nuovo repository:

git init

aggiungiamo i nostri files e facciamo il nostro primo commit (fate riferimento ad una guida sui comandi git).

Ora passiamo alla branch develop:

git checkout -b develop master
Switched to a new branch 'develop'

Ora possiamo propagare la nostra branch sul server (si presuppone origin il nostro remote):

git push -u origin develop
Counting objects: 3, done.
Writing objects: 100% (3/3), 195 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To ...

 * [new branch]      develop -> develop

Per ogni nuova funzionalità lo sviluppatore inizierà una nuova branch partendo dalla branch develop, è preferibile utilizzare un nome come “feature-xyz”, esempio:

git checkout -b feature-xyz develop

Dopo aver implementato la funzionalità richiesta bisognerà integrare lo nostra nuova branch in quella di sviluppo effettuando un merge.

È preferibile effettuare prima un rebase per mantenere la storia più pulita, all'interno della branch feature-xyz:

git rebase develop
First, rewinding head to replay your work on top of it...
Applying: ...

Possiamo anche utilizzare l'opzione -i di git rebase per meglio controllare il processo (fate riferimento al comando git rebase).

Ora torniamo alla nostra branch develop ed effettuiamo il merge della branch feature-xyz:

git checkout develop

Switched to branch 'develop'
Your branch is up-to-date with 'origin/develop'.
git merge --no-ff feature-xyz

Merge made by the 'recursive' strategy.

Come notate ho aggiunto il parametro --no-ff al comando merge, è necessario per avere sempre un commit contente il merge, anche se siamo fast-forward, altrimenti in questo caso si perderebbe traccia del merge.

A questo punto possiamo eliminare la nostra feature branch:

git branch -d feature-xyz
Deleted branch feature-xyz (was c69381c).

e se volete eliminarla anche dal vostro remote

git push origin :feature-xyz

To ...
 - [deleted]         feature-xyz

A questo punto se abbiamo altre feature branch in corso possiamo pensare di effettuare un merge da develop a tutte le altre feature branch, questa operazione è solitamente da evitare quanto più possibile poiché rende la storia poco lineare. Linus Torvalds (autore di git) consiglia di effettuare questa operazione a "momenti ben precisi" della branch upstream (la branch che andremo a mergiare).

Se lo sviluppatore è solo nel progetto è anche possibile effettuare un rebase delle feature branch su develop, purtroppo questo non è sempre fattibile e implica un push forzato se abbiamo anche repository sul mirror remoto, cosa da evitare se altri stanno seguendo lo sviluppo.

Quando siamo fiduciosi di voler fare una nuova release, possiamo effettuare un merge della branch develop sulla branch master ed effettuare un tag della release.

git checkout master
Switched to branch 'master'

git merge --no-ff develop
Merge made by the 'recursive' strategy.

E poi il tag

git tag -a v1.0.0

L'argomento -a forza git ad effettuare un commit per l'aggiunta del tag, non è obbligatorio ma è consigliato.

Vi ricordo che per propagare i tags sul vostro repository remoto occorre il comando:

git push --tags

Può capitare la necessita di dover effettuare una correzione di un problema in tempi rapidi, in questo caso è necessario seguire una diversa procedura. A partire dall’ultima versione di master si crea una nuovo branch locale che qui chiameremo “hotfix-problemaxyz” (il nome è indicativo).

Dopo aver effettuato le nostre correzioni e i nostri commit, questa branch deve essere mergiata su develop e su master da cui verrà fatta una nuova release/tag.

Se il team di sviluppo è composto da più persone è preferibile evitare i merge da remoto a locale sulla stessa branch, questo avviene quando non si è allineati al remote e un altro sviluppatore ha effettuato un push delle sue modifiche.

Questi merge, anche chiamati trivial merge, sono caratterizzati dal messaggio:

Merge branch 'develop' of git@xxxxx

quando la vostra branch locale è develop.

Per evitare ciò è consigliabile di effettura il pull aggiungendo l'opzione --rebase, o in alternativa, se si è già effettuato il pull:

git rebase origin/develop

In seguito un disegno esplicativo