Wiki Ubuntu-it

Indice
Partecipa
FAQ
Wiki Blog
------------------
Ubuntu-it.org
Forum
Chiedi
Chat
Cerca
Planet
  • Pagina non alterabile
  • Informazioni
  • Allegati
  • Differenze per "Programmazione/Git/Branch"
Differenze tra le versioni 7 e 8
Versione 7 del 06/12/2014 02.13.52
Dimensione: 10293
Autore: jeremie2
Commento:
Versione 8 del 06/12/2014 12.34.36
Dimensione: 10317
Autore: jeremie2
Commento:
Le cancellazioni sono segnalate in questo modo. Le aggiunte sono segnalate in questo modo.
Linea 188: Linea 188:
<<Anchor(log_master)>>
Linea 199: Linea 200:
}}}Si può vedere che nel branch master e' stato creato un nuovo commit, che è il commit di merge. Il suo commento dice che è stato effettuato il merge del branch '''gp-1'''. Questo significa che le modifiche che abbiamo apportato su questo branch sono state riportate sul branch corrente ('''master'''). }}}Si può vedere che nel branch master è stato creato un nuovo commit, che è il commit di merge. Il suo commento dice che è stato effettuato il merge del branch '''gp-1'''. Questo significa che le modifiche che abbiamo apportato su questo branch sono state riportate sul branch corrente ('''master''').


Problemi in questa pagina? Segnalali in questa discussione

Introduzione

Git è molto potente per quanto riguarda i branch (rami di sviluppo paralleli). Possono essere creare alberature del repository anche molto complesse in modo veloce da gestire.

Per poter seguire la seguente guida si presuppone:

  • di aver creato il progetto gitproject come indicato;

  • di aver elaborato il progetto come mostrato nella seguente pagina.

Creazione del branch secondario

Verrà ora creato un ramo di sviluppo del progetto chiamato gp-1 separato dal ramo principale master.

  1. Spostati all'interno della cartella del progetto:

    cd gitproject
  2. Per visualizzare i branch attivi digitare:

    git branch

    verrà restituito:

    * master
    che indica l'unico branch attivo.
  3. Per creare un nuovo branch col nome gp-1 digitare:

    git branch gp-1
  4. Verificare nuovamente la lista dei branch:

    git branch

    che ora restituirà:

      gp-1
    * master

    L'asterisco identifica il branch attivo, quello su cui stiamo lavorando in questo momento.

  5. Per lavorare sul branch gp-1 occorre il comando checkout, che ci permette di effettuare lo switch fra i branch:

    git checkout gp-1

    che stamperà un messaggio di conferma del passaggio:

    Si è passati al branch 'gp-1'
  6. Come ulteriore riprova è possibile verificare quale sia il branch attivo:

    git branch

    L'output:

    * gp-1
      master
    conferma che il branch gp-1 segnalato con l'asterisco è il branch attivo.
  7. Il log:

    git lg

    L'output:

    * 1412239 (HEAD, master, gp-1) - user : Aggiunta data in stampa. (2 minutes ago)
    * e1e5a46 - user : Aggiunti sorgenti e Makefile (5 minutes ago)
    * e9ea39b - user : README aggiunto (12 minutes ago)
    mostra entrambi i branch. Dato che ancora sono identici puntano allo stesso commit.

Modifiche al branch secondario

  1. Apportare le modifiche al file ~/gitproject/src/main.cpp digitando:

    sed -i '3 a \\tstd::cout << "Issue gp-1 implementata" << std::endl;' src/main.cpp
  2. Visualizzare il contenuto modificato del file digitando:

    cat src/main.cpp

    che risulterà:

    #include <iostream>
    int main() {
        std::cout << "Thu Dec  4 14:48:20 CET 2014: Benvenuti su Git!" << std::endl;
        std::cout << "Issue gp-1 implementata" << std::endl;
        return 0;
    }
  3. Controllare quindi lo stato:

    git status

    che risulta:

    Sul branch gp-1
    Changes not staged for commit:
      (use "git add <file>..." to update what will be committed)
      (use "git checkout -- <file>..." to discard changes in working directory)
    
            modified:   src/main.cpp
    
    no changes added to commit (use "git add" and/or "git commit -a")

    Possiamo vedere che Git si è accorto della modifica, ma anche che stiamo modificando il nuovo branch (il messaggio mostra il nome del branch su cui stiamo lavorando).

  4. Eseguire il commit:

    git commit -a -m "Modificato codice per issue gp-1."

    L'output sarà:

    [gp-1 d8b610a] Modificato codice per issue gp-1.
     1 file changed, 1 insertion(+)
  5. Consultare il log:

    git lg

    che risulterà:

    * d8b610a (HEAD, gp-1) - user : Modificato codice per issue gp-1. (18 seconds ago)
    * 1412239 (master) - user : Aggiunta data in stampa. (4 minutes ago)
    * e1e5a46 - user : Aggiunti sorgenti e Makefile (7 minutes ago)
    * e9ea39b - user : README aggiunto (14 minutes ago)
    Il branch master è rimasto inalterato (infatti è rimasto al commit precedente), mentre nel nuovo branch è stato memorizzato il commit appena creato.

Verifica del programma nei branch

Ovviamente se proviamo ad eseguire il programma otteniamo l'output modificato con la nostra aggiunta:

  1. Eseguire il programma nel branch gp-1 digitando i comandi:

    make clean && make && bin/main

    l'ultimo comando restituirà:

    Thu Dec  4 14:48:20 CET 2014: Benvenuti su Git!
    Issue gp-1 implementata
  2. Tornare nel branch master:

    git checkout master
  3. Eseguire il programma nel branch master digitando i comandi:

    make clean && make && bin/main

    l'ultimo comando restituirà:

    Thu Dec  4 14:48:20 CET 2014: Benvenuti su Git!
    Come è possibile constatare si è ancora allo stato precedente, prima di eseguire il branch. A questo punto nel log si puo' vedere una cosa interessante:
  4. Consultare il log:

    git lg

    da cui risulta

    * d8b610a (gp-1) - user : Modificato codice per issue gp-1. (2 minutes ago)
    * 1412239 (HEAD, master) - user : Aggiunta data in stampa. (6 minutes ago)
    * e1e5a46 - user : Aggiunti sorgenti e Makefile (8 minutes ago)
    * e9ea39b - user : README aggiunto (16 minutes ago)

    Da notare HEAD che desso punta al commit master.

HEAD è quindi un puntatore al commit in cui attualmente ci troviamo. È possibile spostarsi in qualsiasi commit, non solo sugli ultimi dei rispettivi branch, digitando:

git checkout SHA1

dove SHA1 è il codice SHA1 del commit (i valori d8b610a, 1412239, ecc.. mostrati nel log).

Modifica al branch principale

Dall'ultimo log risulta di essere posizionati sul branch master e supponiamo di voler aggiungere una cartella di documentazione.

  1. Creare la directory doc:

    mkdir doc
  2. Creare il file ~/gitproject/doc/Changelog:

    echo '== Changelog =='$'\n'$'\n''First release' > doc/Changelog
  3. Visualizzare il contenuto:

    cat doc/Changelog

    che risulterà:

    == Changelog ==
    
    First release
  4. Aggiungere i file ed seguire il commit:

    git add doc/
    git commit -a -m "Aggiunta cartella documentazione."

    che risulterà:

    [master e4064d8] Aggiunta cartella documentazione.
     1 file changed, 3 insertions(+)
     create mode 100644 doc/Changelog
     0. Consultare il log:{{{
    git lg

    che risulterà:

    * e4064d8 (HEAD, master) - user : Aggiunta cartella documentazione. (17 seconds ago)
    | * d8b610a (gp-1) - user : Modificato codice per issue gp-1. (5 minutes ago)
    |/  
    * 1412239 - user : Aggiunta data in stampa. (9 minutes ago)
    * e1e5a46 - user : Aggiunti sorgenti e Makefile (11 minutes ago)
    * e9ea39b - user : README aggiunto (19 minutes ago)

    È possibile notare come adesso i due branch stiano prendendo strade parallele. Sono partiti da un punto in comune, ma ognuno sta avendo modifiche indipendenti.

Merge

Adesso siamo nella situazione in cui:

  • il branch master ha aggiunto la documentazione;

  • il branch gp-1 ha implementato una feature.

Verrà effettuato un merge ossia introdurre le modifiche fatte in un branch in un altro branch.
In particolare, vogliamo che nel branch master vengano introdotte le modifiche aggiunte nel branch gp-1. Vogliamo quindi effettuare il merge di gp-1 su master.

Il comando per effettuare i merge in Git sarà del tipo:

git merge ALTRO_MERGE
  1. Assicurarsi di essere nel branch master:

    git branch

    cioé che risulti:

      gp-1
    * master
  2. Effettuare quindi il merge:

    git merge gp-1

    il cui output sarà:

    Merge made by the 'recursive' strategy.
     src/main.cpp |    1 +
     1 file changed, 1 insertion(+)

  1. Consultare il log:

    git lg

    che restituisce:

    *   f61b2e2 (HEAD, master) - user : Merge branch 'gp-1' (9 seconds ago)
    |\  
    | * d8b610a (gp-1) - user : Modificato codice per issue gp-1. (7 minutes ago)
    * | e4064d8 - user : Aggiunta cartella documentazione. (3 minutes ago)
    |/  
    * 1412239 - user : Aggiunta data in stampa. (11 minutes ago)
    * e1e5a46 - user : Aggiunti sorgenti e Makefile (14 minutes ago)
    * e9ea39b - user : README aggiunto (21 minutes ago)

    Si può vedere che nel branch master è stato creato un nuovo commit, che è il commit di merge. Il suo commento dice che è stato effettuato il merge del branch gp-1. Questo significa che le modifiche che abbiamo apportato su questo branch sono state riportate sul branch corrente (master).

  2. Per verificare che le modifiche apportate su gp-1 siano state incluse nel master, visualizzare il contenuto del file ~/gitproject/src/main.cpp, digitare:

    cat src/main.cpp

    che restituisce:

    #include <iostream>
    int main() {
        std::cout << "Thu Dec  4 14:48:20 CET 2014: Benvenuti su Git!" << std::endl;
        std::cout << "Issue gp-1 implementata" << std::endl;
        return 0;
    }
  3. Digitare i comandi:

    make clean && make && bin/main

    L'ultimo comando restituirà:

    Thu Dec  4 14:48:20 CET 2014: Benvenuti su Git!
    Issue gp-1 implementata

Conclusioni

  • È stato creato un branch secondario.
  • È stata applicata una issue al branch secondario.

  • Sono state riportate le modifiche sul branch principale.

E' importante notare che quello che e' stato appena fatto non è un mero esercizio. È il modo standard in cui si lavora in Git con progetti seri. Di solito i passi da effettuare sono i seguenti:

  1. Si decide la issue da aggiungere/rimuovere/modificare.
  2. Dal branch principale si crea un nuovo branch, con un nome identificativo della modifica (può essere il codice associato a Bugzilla, il nome gp-1 ne è un esempio).

  3. Si lavora alla issue su branch secondario.
  4. Quando si completa, si effettua il merge sul branch principale in modo che il progetto includa le modifiche e siano rese pubblicamente disponibili.

Questo modo di lavorare permette di fare tutte le sperimentazioni del caso sul proprio branch, senza la preoccupazione di andare ad intaccare il progetto sul ramo principale che ne rimarrà immune fino a quando la issue non è completamente testata e funzionante.

Se nel frattempo arriva un'altra issue più urgente (un bug da risolvere o quant'altro), viene semplicemente creato un altro branch da quello principale, come fatto in precedenza, e si lavora su quello. I branch sono indipendenti fra di loro e questo assicura grande flessibilità nella gestione del progetto.

Ulteriori risorse


CategoryProgrammazione