Distribuisci il ramo di cui hai bisogno dove necessario.
Ora, ovviamente non hai intenzione di distribuire un ramo di funzionalità alla produzione. Tuttavia, la distribuzione dell'ultima build dal master allo sviluppo non dovrebbe essere un problema.
Il ramo di sviluppo in git-flow riguarda il fatto di essere la linea principale - quella da cui il normale processo ti separa e si fonde. L'unica eccezione a questo processo è quella del ramo di aggiornamento rapido in cui è necessario acquisire la corrente dalla produzione.
Vediamo un po 'più questo aggiornamento rapido e consideriamo quale sarebbe il processo di distribuzione quando si hanno tre posizioni. Probabilmente dovresti implementare la nuova hot fix da svuotare, fare alcuni commit su quel ramo e poi distribuirlo a QA e poi a prod.
Per un normale processo di rilascio con git-flow è probabile che si stiano facendo build fuori dal server di sviluppo su development branch. Una volta che si diramano per release , è probabile che il capo del ramo si diriga verso il server di sviluppo (quindi gli sviluppatori che lavorano sullo sforzo di rilascio possono vedere qual è lo stato corrente) e rami specifici taggati che vanno al QA. Una volta che QA esegue uno dei build taggati, il ramo di rilascio di quel tag viene unito in master e quindi master viene taggato e distribuito in produzione.
probabilmente vuoi avere più ambienti per dev. Il capo di release è un ambiente di distribuzione, il capo di development è un altro ambiente di distribuzione e forse anche un capo di feature è un altro uno o cinque.
Dovresti essere in grado di creare qualsiasi ramo per qualsiasi profilo di ambiente di distribuzione. Distribuire la produzione corrente al server dev dovrebbe essere fattibile.
Git-flow stesso è ortogonale al punto in cui distribuisci le cose. Si tratta di fare in modo che i diversi rami dispongano di un insieme limitato e definito di ruoli. Limitando i ruoli rende più facile ragionare su cosa sta facendo ogni ramo e su quale sia il suo stato in un dato momento.
L'unica cosa che git-flow prova a dire su dove vengono implementate specifiche cose è che il capo di master è la produzione. Qualcos'altro su ciò che distribuisci dove nel tuo ambiente è un problema specifico del sito. Git-flow funziona altrettanto bene con una sola produzione e gli sviluppatori che eseguono tutte le altre distribuzioni sui loro server locali come fa per avere produzione, staging, qa, dev e dozzine di feature server.
I passaggi per eseguire una distribuzione su qualsiasi server specifico sono completamente fino al flusso di lavoro locale per quel server.