Bugfixing per ScrumDo

Un caso d'uso reale "avanzato" di git

Il nostro ScrumDo è , in pratica, un fork del package ScrumDo ufficiale.

Il package ufficiale è suddiviso in branch, tra le quali le principali sono la master e la production (da cui "ereditiamo" le nostre branch).

Ovviamente i bug vengono rilevati sulla nostra istanza di produzione sulla quale è installata la nostra versione di ScrumDo con branch=production; dunque la fase di bugfixing va ad impattare questa branch (e non direttamente la master).

Il concetto quindi è: noi dobbiamo portare i nostri bugfixes sulla branch production e poi riportarli alla master in modo che poi possiamo fare una pull-request ai gestori del progetto ScrumDo.

Per fare ciò bisogna innanzitutto accertarsi di aver allineato la nostra master con la loro, quindi:

  • switchare sulla branch nostra master:

git checkout master

  • aggiungere la loro repo come altra remote:

git remote add scrumdo git://github.com/ScrumDo-Dev-Group/ScrumDo.git

  • fare un git fetch della loro master:

git fetch scrumdo

  • creare una nuova branch locale legata alla loro master:

git branch -t scrumdo-master remotes/scrumdo/master

  • effettuare il merge con la master remota:

git merge scrumdo-master

  • fare il push della nostra nuova master:

git push origin master

I nostri bugfixes li abbiamo (sicuramente) effettuati sulla branch production che va dunque allineata alla nuova master prima di poter pushare in tutta sicurezza le correzioni.

A questo punto entra in gioco il comando "git rebase" (http://book.git-scm.com/4_rebasing.html).

Questo comando permette di riscrivere la storia del ramo corrente, a partire dalla versione specificata; in pratica viene identificato il punto di biforcazione del ramo corrente e di quello su cui si sta ri-basando, si riavvolgono tutti i commit successivi a tale separazione, si applicano quelli che portano dalla biforcazione alla nuova base, vengono poi ri-applicati quelli del ramo locale, gestendo eventuali differenze.

Il rebase lo effettuiamo a partire da una branch locale di "appoggio" (dalla quale non partiranno mai dei push e che verrà cancellata subito dopo aver effettuato l'operazione di rebase).

Quindi:

  • ci spostiamo sulla branch production

git checkout production

  • creiamo la nuova branch di appoggio:

git branch bugfixing

  • ci spostiamo sulla nuova branch:

git checkout bugfixing

  • effettuiamo il rebase:

git rebase master

  • ci spostiamo sulla branch master:

git checkout master

  • effettuiamo il merge dalla branch di appoggio:

git merge bugfixing

  • eliminiamo la branch di appoggio:

git branch -d bugfixing

  • effettuiamo il push della master con le correzioni:

git push origin master

Il gioco è fatto, a questo punto abbiamo una branch master allineata con quella ufficiale di ScrumDo e con le correzioni necessarie. Possiamo quindi inoltrare una "pull request" ai maintainers del progetto per sottoporgli le nostre correzioni.

Share this on

Share |

On same topics

Commenti

comments powered by Disqus