Mantenere una cronologia di git pulita quando si utilizza gitflow

Usando gitflow, quando si crea un release-1.0.0ramo e si unisce a entrambi mastere develop, entrambi i rami avranno un commit mancante:

masternon avrà il commit dove è release-1.0.0stato unitodevelop
developnon avrà il commit dove è release-1.0.0stato unitomaster

Invece, dopo che hotfix-1.0.1viene creato e unito a master, quando viene unito a develop, i commit da unire includeranno il commit precedente in cui è release-1.0.0stato unito master; così sarà simile a questo:

User 'john doe' is trying to merge the following commits into 'develop' from 'hotfix-1.1.1'.

* merge release-1.0.0 to master
* merge release-1.1.0 to master
* Fix shopping cart critical bug

Se questo suona confuso, puoi facilmente notare che ogni individuo che vedi developè di solito un paio di commit dietro master(anche se teoricamente, lo sviluppo dovrebbe essere solo avanti dal momento che è il ramo principale. Questi commit sono fusioni da release-x.x.xa master).

Come dovrebbe essere gestito per mantenere una storia pulita?

git gitflow

— Christopher Francisco
fonte

Si prega di definire "cronologia pulita".

— Jace Browning,

Vuoi una storia pulita? Non usare gitflow. Per definizione inquina la tua storia. Invece, pensa a ciò di cui hai veramente bisogno e crea un flusso di lavoro attorno a ciò, in modo che si adatti effettivamente al modo in cui vuoi lavorare.

— FP

L'unione da padroneggiare sarà una "copia", non è necessario unirla per svilupparla. Apporta correzioni rapide dal ramo di rilascio precedente, non da master, e uniscili ad entrambi da lì, e non avrai il problema. Master non sta aggiungendo molto al modello, quindi puoi rilasciarlo completamente, IMO.

— axl,

@axl Capisco cosa intendi, ma sto cercando di seguire gitflow il più vicino possibile alla sua documentazione. Preferirei non fare alcun tipo di "hackz" perché poiché gitflow è già adottato da molti molti sviluppatori, dovrebbero già avere una soluzione per questa cosa semplice

— Christopher Francisco

Ci sono diverse discussioni su come risolvere vari problemi con GitFlow su GitHub e altri luoghi. A volte non c'è proprio un proiettile d'argento.

— axl

Penso che un buon approccio sia quello di evitare di avere due rami "principali", master e sviluppo sono in qualche modo ridondanti. È spiegato a fondo qui , marchiato cactus-flowdall'autore.

Alcuni punti si distinguono rispetto al flusso git:

Solo un ramo principale
Solo le fusioni con avanzamento rapido

Per me l'ultimo è importante, poiché dopo aver usato git-flow per molto tempo devo ancora vedere cosa è utile sulle --no-fffusioni.

Sto cercando di seguire gitflow il più vicino possibile alla sua documentazione. Preferirei non fare alcun tipo di "hackz" perché poiché gitflow è già adottato da molti molti sviluppatori, dovrebbero già avere una soluzione per questa cosa semplice

IMHO questo è il tuo grande errore. Non c'è motivo per cui ti attacchi al git-flow il più possibile. Può essere utilizzato in migliaia di progetti ma ciò non influisce sui tuoi, non lo rende buono.

Git-flow è un buon punto di partenza, ma dovresti pensare di adattarlo ai tuoi strumenti e al tuo flusso di lavoro piuttosto che viceversa.

— Sergio Basurco
fonte

Mantenere una cronologia di git pulita quando si utilizza gitflow - impegni immersi sullo sviluppo