Evitare Grid of Doom ™ in Git-Flow

Question

Evitare Grid of Doom ™ in Git-Flow

#1 da (1 voti)

8

Il mio progetto segue il modello di branching Git Flow . Lo sviluppo avviene su develop , che viene unito in master e taggato lì per le versioni. Gli aggiornamenti rapidi si verificano nelle filiali ramificate fuori dall'attuale master .

Tuttavia, lo sviluppo corrente richiede anche gli hotfix, quindi ogni ramo di aggiornamento rapido viene unito anche a develop .

Questo crea grafici di revisione molto brutti, in particolare lo sviluppo / gli aggiornamenti rapidi vengono uniti spesso in un breve lasso di tempo:

Questo è un problema che le persone hanno di solito con Git-Flow e c'è una soluzione semplice per questo?

git gitflow

posta Hannes Struß 08.05.2015 - 14:33

fonte

1 risposta

Leggi altre domande sui tag git gitflow

Refactoring di un'API client per evitare il codice duplicato e il passaggio non chiaro dei parametri Trovare tutti i modi possibili per inserire un motivo in una stringa

score 1 · Answer 1

so your problem is that you're merging every hot fix two or three times? (First to master, then to develop, lastly from develop to master again)?

sì, è così! Tuttavia, non è possibile evitarlo, gli aggiornamenti rapidi devono essere uniti nello sviluppo

Certo, ma perché fondersi dallo sviluppo al master se nulla è realmente cambiato?

Dai un'occhiata a una di quelle master<-develop<-hotfix merges: non ci dovrebbero essere cambiamenti effettivi (l'hotfix era già stato unito direttamente al master, dopotutto). Se non ci sono cambiamenti, non farlo.

In ogni caso, secondo il tuo documento collegato, le uniche fusioni da sviluppare a master dovrebbero passare attraverso un ramo di rilascio. Invece stai mantenendo il master in sincronia con il tuo ramo di sviluppo (instabile) - no.