SourceTree, Git e primi passi

Per la gestione dei progetti software è ormai uso comune fare ricorso a repository e version control. Un repoitory è in campo software un archivio in cui è contenuto il software che si sta sviluppando e sul quale si può lavorare in team o singolarmete.

Attraverso i version control si possono gestire i repository con la massima flessibilità utilizzando i concetti basilari di git. Tali concetti sono ulteriormente semplificati attraverso l'utilizzo di client come SourceTree.

SourceTree è essenzialmente un'interfaccia grafica al prompt dei comandi di git.  In questo articolo vedremo i concetti basilari per poterlo utilizzare.

Per questo tutorial utilizzeremo BitBucket per gestire i nostri repository. Una volta registrati su BitBucket potremmo creare un repository per gestire un progetto al quale il nostro team lavorerà.

Per creare un repository  basta spostarsi sul seguente percorso, Home -> Create -> Create Repository. A questo punto avremmo difronte una form per gestire il repository come nella figura seguente.

In pratica qui andremo a creare una cartella sul server che ospiterà il nostro progetto.

Il passo successivo è clonare il repository sulla nostra macchina attraverso SourceTree. Aperto il nostro client git clicchiamo su Clone/New ed inseriamo la URL del nostro repository e il percorso dove salvarlo in locale.

Fatto ciò avremo il nostro repository sulla nostra macchina pronto per essere modificato. Di norma è buono stile creare un file Readme per informare il team dei progressi fatti, o nel caso di repository pubblici, informare gli utenti sul lavoro svolto o da svolgere e le tecnologie utilizzate. Creato il nostro file Readme avremo la console di SourceTree che ci informerà sul Worcking Copy della presenza di un file da aggiungere: il nostro Readme.

Il nostro file è pronto per essere "commissionato", il secondo concetto basilare di git. Un “commit”  indica quali modifiche sono state eseguite su di un file, segnalando al team quali cambiamenti abbiamo apportato al file. Nel nostro caso (icona più) abbiamo creato un nuovo file. Una volta fatta la commit vedremo creare in automatico il branch master in locale. Se  il repository remoto è ancora vuoto questo branch va inviato al server remoto attraverso un checkout.

E' il momento ora di inserire nel nostro repository locale qualcosa di più di un file Readme... Avviamo Android Studio e inizializziamo il nostro progetto salvandolo nella cartella del repository.

Ora SourceTree ci segnalerà nel nostro Working Copy tutti i file creati da Android Studio e pronti da essere committati su BitBucket. Prima di fare ciò è molto utile modificare il .gitignore in modo da ignorare tutti i file non utili allo share. Quindi recarsi nella cartella del progetto Android, aprire il file .gitignore con un editor di testo e modificare il contenuto con il seguente.

# Built application files
*.apk
*.ap_

# Files for the Dalvik VM
*.dex

# Java class files
*.class

# Generated files
bin/
gen/

# Gradle files
.gradle/
build/

# Local configuration file (sdk path, etc)
local.properties

# Proguard folder generated by Eclipse
proguard/

# Log Files
*.log

# Android Studio Navigation editor temp files
.navigation/

# Android Studio captures folder
captures/

 In questo modo tutti i file e cartelle non utili al progetto saranno ignorati dal Working Copy.

Ora possiamo iniziare a committare il nostro progetto su BitBucket. Nel nostro Woring Copy selezioniamo i file in modo da averli nell'area di stage pronti ad essere committati. 

Fatta la commit SourceTree ci segnalerà una push su master relativa alla commit "first commit" precedente e cioè ai file del nostro progetto. 

 L'idea generale di Git-Flow è quello di utilizzare la seguente struttura per il  repository:

• Development branch: Questo è il branch di sviluppo principale dove si faranno tutte le modifiche destinate per il prossimo rilascio
• Production branch: Solitamente chiamato 'master' questo branch rappresenta l'ultimo rilasciato distribuito. Questo branch è solitamente aggiornato dal merge di altri branch
• Feature branches: Quando si inizia a lavorare su qualcosa di non banale, si crea un branch feature. Una volta terminato, va fatto il merge sul branch dev e poi rilasciata l'ultima release
• Release branches: Quando si è in procinto di rilasciare una nuova release, si crea un branch di release dal branch di sviluppo
• Hotfix branches: Se avete bisogno di patchare l'ultima versione senza creare altri feature branch per il branch di sviluppo, è possibile creare un branch hotfix dall'ultimo codice distribuito sul master.

 SourceTree è molto utile nella gestione del Git-Flow e facilita molto il compito per la creazione della struttura sopra elencata.

Una volta inizializzato Git Flow avremo nel nostro repository locale un nuovo branch chiamato develop (dev nel nostro esempio). 

Per far in modo che tutti gli utenti del nostro team possano lavorare allo stesso branch di sviluppo può essere utile inviarlo al repository remoto

Tutte le modifiche fatte al nostro progetto andranno committate sul branch dev in modo da poter poi utilizzare la struttura del Git-Flow. Apportate le seguenti modifiche vediamo come utlizzare questo strumento.

 @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        TextView mText = (TextView) findViewById(R.id.text);
        mText.setText("SourceTree");
    }

Le ultime due righe di codice modificano la classica scritta Hello World con SourceTree. A questo punto andiamo a fare una commit su dev e push sul repository remoto.

Spostandoci sul repository remoto possiamo vedere come le modifiche appena aggiunte sono visibili sul branch dev, mentre quello master risulta sempre quello della release iniziale.

Adesso possiamo creare la release v1.0.0 che si riferisce al progetto Android che stampa SourceeTree sull'Activity. Spostandoci su Git-Flow andiamo a scegliere start new release, inseriamo il tag v1.0.0, all'ok SourceTree creerà un branch release dove andrà committato il bump version (in questo caso v1.0.0). Prima di terminare la release andiamo sul build gradle e cambiamo il version name in 1.0.0 ed il version code in 100. Facciamo una commit sul branch release e terminiamo la release da Git-Flow.