In Gitflow Workflow , un hotfix è un ramo creato da master e alla fine viene riunito nel master AND in develop.
L'idea generale (e ben nota) dietro al "non commettere direttamente sul master", è avere in master uno stato del tuo codice che è completamente sicuro da distribuire in produzione.
Tuttavia, può servire altri mezzi. Per Github , il master funge anche da strumento di monitoraggio per sapere quando una funzionalità viene messa in produzione. Se esegui il commit su un altro ramo e fai avanzare rapidamente il master su di esso, perderai il commit di merge e, per estensione, inserirai un sacco di piccoli commit nella tua timeline principale, perdendo la possibilità di annullare un'intera funzione di semplicemente ripristina l'unione precedente.
Un altro problema con questo approccio è sapere QUANDO è possibile rilasciare / distribuire. Se tutti si impegnano sul master, dovrai sincronizzare tutto lo sviluppo per avere uno stato coerente del tuo codice. Per le versioni monolitiche con un ambito chiaro, può essere ok, ma nel mio caso, come sviluppatore di integrazione, le funzionalità vanno e vengono e non hai mai un singolo punto nel tempo in cui "tutte le funzioni sono state eseguite".
Tuttavia, non impegnarsi in master non significa avere un master di ramo e uno sviluppo. Come indicato nella presentazione di Github, se esegui un flusso di lavoro delle branch caratteristiche , può funzionare solo con un master, creando un ramo per ogni funzione e unendoli nuovamente in master (senza avanzamento rapido) alla fine.
A mio modesto parere, Git Flow (master / sviluppo + funzioni / hotfix / rami di rilascio) è più adatto in un contesto in cui non si sa veramente quando sarà necessario rilasciarlo (non per ogni funzione eseguita) e quando l'ultima versione è spesso quella dell'aggiornamento rapido. Un grafico gitflow può essere contorto, mentre un flusso di lavoro di ramificazione delle funzionalità è spesso più semplice da leggere. Il "rumore" è spesso dovuto al rilascio / hotfix di commit in quello che verrà eliminato dopo alcuni minuti.
Esempio per Gitflow
Esempio di grafico per Flusso di lavoro Feature Branching
