Re: [linux_var] Git

[Luca Lesinigo <luca@lesinigo.it>]

Il giorno 21 feb 2017, alle ore 15:20, Michele V. <akrobaticone@gmail.com> ha scritto:
> quindi rebase è l'extrema ratio
> ma perchè uno è costretto ad usarlo?
> 
> la cosa mi ha particolarmente incuriosito......
> mandatemi pure a stendere
Esempio più realistico di un “buon” caso d’uso del rebase...

Devi sviluppare qualcosa su un progetto e quindi ti fai un tuo branch locale e ci lavori sopra:
	git clone awesome_project my_repo
	(il clone ha un “git checkout master” implicito)
	git checkout -b super_new_feature
	(lavori lavori lavori)
	git commit
	(nb il commit è sul tuo super_new_feature e *non* ne fai push)

Passa del tempo, durante il quale il branch master o qualsiasi sia quello da cui hai forkato è andato avanti.
Tu finisci il tuo lavoro e sei pronto a farne il merge o chiedere di farne il merge a chi di dovere, ma fino ad oggi non ne avevi mai fatto push ad estranei.
Se mandassi fuori il tuo branch così com’è il merge in master sarebbe “complicato” perché le tue diff vanno applicate al master attuale che è diverso da quello da cui eri partito.

Quindi _prima_ di chiedere il merge (e prima di aver condiviso con chiunque nel mondo il tuo branch) fai un git rebase del tuo branch sull’attuale master.
Nel fare il rebase ti smazzi tu, che conosci bene il tuo lavoro sul tuo branch, eventuali conflitti per allinearlo al nuovo master.
	git checkout master
	git pull
	git checkout super_new_feature
	git rebase master
	(bestemmi bestemmi bestemmi)
	(i conflitti sono risolti in fase di rebase e ancora non c’è alcun merge)

Solo a quel punto mandi avanti la pull request / merge request / qualsiasicosasia:
	(sei su super_new_feature)
	git push --set-upstream origin super_new_feature
	(mandi fai una pullrequest chiedendo di mergiare super_new_feature in master)

Ora chi deve fare il merge si trova delle diff che applicano senza alcun conflitto sul master attuale e quindi è molto più felice.
Il merge commit sarà molto pulito, per non dire totalmente senza contenuti, in effetti se è successo alla lettera quanto ho descritto potrebbe essere un fast forward merge e dalla storia del repo risulterebbe uno sviluppo completamente lineare, senza alcun vero merge commit (cioè senza nessun commit con due parent).

Il merge senza prima un rebase demanda al merge commit la risoluzione dei conflitti, non sarebbe un fast forward e rimarrebbe traccia nella storia di un branch parallelo che poi è stato integrato in master con un merge commit (cioè un commit con due parent). Se sia preferibile questo al caso precedente, o se uno dei due casi non sia proprio attuabile e quindi per esclusione si va sull’altro, dipende molto anche dalle politiche interne del team… o se vuoi dirla in modo molto “2.0” dipende dal workflow di sviluppo adottato dal team.

Il rebase si può applicare in molte situazioni, quella descritta è una delle poche che (imho) ne potrebbe giustificare l’uso e non rappresenta un problema (questo perché ci basiamo sul presupposto che non hai mai push’ato il tuo branch a terzi). In questo specifico caso il fatto di fare un merge tradizionale od un rebase+merge serve esclusivamente a spostare l’operazione di risoluzione dei conflitti: con il merge li risolve chi fa il merge quando fa il merge, con il rebase li risolve chi fa il rebase quando fa il rebase ed il merge diventa lineare e senza conflitti.

--
Luca Lesinigo

_______________________________________________
Talking mailing list
Talking@ml.linuxvar.it
http://ml.linuxvar.it/cgi-bin/mailman/listinfo/talking