Dovrei avere un ramo 'dev' separato da un ramo 'produzione'?

5

Recentemente ho installato i miei ambienti di server di staging e produzione su Heroku e tutto funziona alla grande. Attraverso Heroku, puoi schierare da un ramo Git - ad es. master o my-feature . Questo mi ha fatto pensare: dovrei avere un dev branch?

Il ramo dev funzionerebbe essenzialmente come stage corrente in development ; branch my-feature verrebbe unificato in dev una volta completato. Quindi distribuirò dev al mio ambiente di gestione temporanea e, se tutto verrà risolto, vorrei unire dev in master e distribuire master a produzione .

A prima vista, per me questo ha senso come un flusso di lavoro. Guardando i rami, è immediatamente evidente ciò che è in sviluppo e ciò che è in produzione. Con il consueto ramo master attivamente sviluppato e distribuito, è difficile tracciare la linea a colpo d'occhio senza guardare timestamp o hash di commit SHA.

L'unico lato negativo che riesco a vedere è che i miei registri di commit hanno fondamentalmente un commit unito dev con master per ogni distribuzione in produzione. Personalmente non vedo questo come un grosso problema, perché aiuta a definire la linea quale codice viene utilizzato dalla produzione? .

Avere un ramo dev ha senso se viene usato in questo modo?

PS - Sto lavorando da solo a questo progetto. Sono curioso di sapere se questo ha un senso come flusso di lavoro generale per gli sviluppatori.

    
posta Chris Cirefice 13.06.2016 - 05:17
fonte

2 risposte

7

Ritengo che questo sia eccessivo per una singola persona che lavora su una singola applicazione Web.

Vorrei utilizzare i tag per fornire i numeri di versione alle versioni rilasciate sul server di produzione. Il server di staging può utilizzare solo l'ultimo commit su master, mentre la produzione utilizza un tag.

Avere uno script di "rilascio" che aggiorna i file con il nuovo numero di versione, li impegna, quindi contrassegna il commit con quel numero di versione.

    
risposta data 13.06.2016 - 13:12
fonte
5

Sì, questo è un flusso di lavoro comune. Il popolare flusso di lavoro gitflow ha un ramo di sviluppo separato, per esempio.

Diversi team usano diversi flussi di lavoro. Che deriva da diverse composizioni di squadra. I flussi di lavoro che funzionano per progetti open source con un numero elevato di collaboratori esterni potrebbero non funzionare necessariamente per progetti aziendali interni o per progetti personali. Non esiste un buon flusso di lavoro che funzioni per tutti.

    
risposta data 13.06.2016 - 05:55
fonte

Leggi altre domande sui tag