La tendenza del ramo "sviluppo" sta scomparendo

82

Ultimamente ho notato qualcosa guardando alcuni progetti popolari su GitHub, che non ci sono developfiliali. E infatti, neanche la guida GitHub Flow ne parla. Da quanto ho capito, masterdovrebbe essere sempre totalmente stabile e riflettere la produzione. Se gli sviluppatori stanno lavorando su rami di funzionalità e quindi fondendo quelli in mastercui hanno finito, ciò significa che c'è un periodo di tempo in cui le funzioni / correzioni vengono unite mastere il masterramo è in realtà più recente della produzione.

Non avrebbe più senso che il team crei funzionalità / risolva i rami da develop, si fonda in quello, e quindi quando la prossima versione è completamente pronta per il rilascio, developviene unita mastere viene creato un tag? Immagina se le persone si stanno unendo direttamente mastere viene segnalato un bug in produzione che diventa difficile da risolvere perché la masterbase di codice della filiale è cambiata in modo significativo. Quindi gli sviluppatori devono solo dire all'utente di attendere fino alla prossima versione per vedere il problema risolto.

EDIT: questa domanda è diversa da "ramificare o non ramificare". Si rivolge in particolare alle persone che si allontanano dall'uso del ramo di sviluppo e le ragioni che lo circondano, poiché è stata propagandata come una buona pratica per lungo tempo.

git github

— ffxsam
fonte

11

Esistono molti possibili flussi di lavoro che git abilita. Non ci si dovrebbe aspettare che gitflow o github siano utilizzati per tutti i progetti.

Domanda molto interessante. Ho lavorato anni con nvie.com/posts/a-successful-git-branching-model e devo dire che mi piace. Quello che mi piace di più è che a) master è ciò che è in produzione e che vale anche per le versioni eb) c'è una chiara differenza tra un aggiornamento rapido e una funzionalità, che vengono avviati e uniti su master e sviluppati rispettivamente. Tuttavia, dopo aver seguito questa discussione, inizio a dubitare che si tratti di cose troppo complicate. Qualche opinione al riguardo?

— Aspasia,

1

Odio l'idea che il maestro sia una registrazione di ciò che è in produzione. Se abbiamo bisogno di sapere cosa c'è in produzione, dovremmo semplicemente interrogare la produzione e non fare affidamento sul master che rifletta accuratamente ciò che è in produzione.

— Jim V,

52

Viene dalla mentalità CI dove c'è integrazione più volte al giorno.

Ci sono pro e contro di entrambi.

Nel nostro team abbiamo abbandonato anche il ramo di sviluppo poiché ritenevamo che non offrisse alcun vantaggio aggiuntivo, ma alcuni svantaggi. Abbiamo configurato il nostro software CI (Teamcity) per compensare gli svantaggi:

Abilita la distribuzione di un commit specifico. In altre parole: non implementiamo un ramo. Distribuiamo un commit.
Siamo in grado di distribuire master o filiali a partire da un aggiornamento rapido / prefisso.

Il motivo per cui funziona è perché tutte le richieste pull contengono codice potenzialmente rilasciabile, ma ciò non significa che distribuiamo tutti i commit nel master.

Il motivo principale per cui abbiamo abbandonato il ramo di sviluppo è perché tendeva a diventare troppo grande e richiede troppo tempo per vedere cosa conteneva effettivamente. Se abbiamo implementato qualcosa un po 'prematuramente, ci limitiamo a diramare un ramo di hotfix e distribuirlo direttamente.

— Esben Skov Pedersen
fonte

11

Avendo lavorato con un ramo di sviluppo per un anno o due, solo per averlo unito al maestro ogni tanto, posso solo dire: amen, abbandona quella cosa:]

— stijn

Interessante. Quindi suppongo che quando rilasci la versione 1.3, ad esempio, tagghi un commit specifico master, quindi se un bug si presenta successivamente mentre si mastertrova in uno stato di flusso, puoi facilmente ramificare un aggiornamento rapido dal tag 1.3?

— ffxsam,

5

Direi che i vantaggi di "sviluppo" dipendono fortemente dal tipo di software che stai realizzando, da come viene distribuito e dalla necessità di supportare più versioni live o meno.

— axl

1

@ffxsam non abbiamo nemmeno bisogno di tagging perché stiamo monitorando quale ID git è attualmente distribuito. Questo è registrato sia in TeamCity che ramificato in DLL distribuite e nel portale di gestione azzurro. Quindi non abbiamo sentito la necessità di ulteriori tag, ad eccezione dei tag automatici eseguiti da TeamCity. Se ritieni che il tagging si adatti meglio al tuo flusso di lavoro, lo risolverà anche bene. Ma sì, in linea di principio si dirama direttamente dalla modifica attualmente distribuita per creare un ramo di aggiornamento rapido.

— Esben Skov Pedersen

25

Un ramo di sviluppo è più importante se il processo di rilascio è complesso e devi disporre di candidati per il rilascio serio.

Ad esempio, immagina di scrivere software che è un firmware su auto. Questo è ... non banale da risolvere ed è probabile che qualsiasi versione abbia un set completo di test non-CI / di integrazione eseguiti su hardware reale.

In tal caso potrebbe essere più sensato isolare un "candidato candidato" in un ramo non master (come "sviluppo"). Ciò consente al team che esegue quei test di disporre di un ramo in cui unire le funzionalità.

Le webapp o altri software facilmente aggiornabili non hanno questo vincolo.

Tuttavia, si noti che:

Molti (la maggior parte?) Progetti su github non hanno questo tipo di vincolo
Un "maestro" principale ha lo stesso scopo
Un flusso di lavoro di "make a PR vs master" è molto più universale di "make a PR contro un ramo che non si conosce immediatamente in questo repository"

— enderland
fonte

18

Ci sono due filosofie che ho visto nei progetti e penso che la scelta sia solo una questione di gusti:

Designare "master" come rilascio di produzione e svilupparlo in un ramo "sviluppo".
Sviluppa in "master" e disponi di un ramo con nomi diversi per versioni di produzione stabili. Ciò ha ancora più senso se il tuo progetto ha più diramazioni di rilascio alla volta (ad esempio, quella preferita corrente è la Release-1.8, ma stai ancora mantenendo la Release-1.7).

Entrambi sono approcci comuni e hanno i loro pro e contro.

— Larry Gritz
fonte

Sono d'accordo con te. Preferiamo avere filiali di rilascio e mantenerle fino al prossimo rilascio in produzione. Se dobbiamo apportare correzioni rapide, controlliamo l'ultimo ramo di rilascio e lavoriamo su quello, quindi uniamo quelle correzioni rapide nel ramo master / sviluppo

— Johnny,

Esattamente. Ciò che il "maestro" dovrebbe fare è principalmente la semantica. La cosa fondamentale da fare è evitare di dover sincronizzare più rami viventi per sempre in modo bidirezionale a meno che tu non abbia una buona ragione per farlo. Il ramo "master" in Git Flow è solo una replica ritardata di "sviluppo", quindi non conta davvero. L'anti-pattern sta permettendo al ramo di sviluppo principale di contenere cambiamenti che non entrano mai in una versione, che è una pratica sorprendentemente comune che ho visto. Entrambi i modelli sopra menzionati impediscono questo, motivo per cui funzionano.

— John Michelau,

7

I rilasci in produzione possono essere taggati, quindi la situazione che è stata rilasciata può sempre essere riprodotta senza dedicare un intero ramo per questo scopo.

Se viene riscontrato un bug critico nella produzione in un momento in cui il master non può essere rilasciato, è abbastanza facile controllare il tag e avviare un nuovo ramo "hotfixes-for-release-1.2.0" da lì. Ma dovrebbe essere piuttosto raro.

Il più delle volte nelle nostre applicazioni web, master è cambiato dall'ultima versione ma non in modo molto significativo, quindi possiamo semplicemente fare una nuova versione da master che ha la correzione. Aiuta comunque a fare rilasci molto frequenti.

— RemcoGerlich
fonte

5

Se gli sviluppatori stanno lavorando su rami di funzionalità e quindi unendo quelli al master quando hanno finito, ciò significa che c'è un periodo di tempo in cui le funzioni / correzioni vengono unite mastere il masterramo è in realtà più recente della produzione.

...

Immagina se le persone si stanno unendo direttamente al master e viene segnalato un bug in produzione che diventa difficile da risolvere perché la base di codice del ramo master è cambiata in modo significativo.

Questo non è Github Flow.

Questo è il processo di distribuzione / unione di Github Flow, in base al tuo link:

schierare

Dopo che la richiesta pull è stata esaminata e la filiale ha superato i test, è possibile distribuire le modifiche per verificarle in produzione. Se il tuo ramo causa problemi, puoi ripristinarlo distribuendo il master esistente in produzione.

fondersi

Ora che le modifiche sono state verificate in produzione, è tempo di unire il codice nel ramo principale.

(Enfasi mia)

In altre parole, masternon sarà mai davanti alla produzione. Allo stesso modo, mastersarà sempre in uno stato stabile e rilasciabile (a parte i bug non scoperti), poiché tutto viene rivisto, testato e implementato in produzione prima di essere unito master.

— 8bittree
fonte

Bello! Questo ha un grande senso intuitivo: masterè sempre la posizione di rollback se il ramo di funzionalità che si inserisce nella produzione fallisce. In caso contrario, viene unito mastere diventa il nuovo fallback. Mi piace.

— Bill Horvath,

1

Il problema che vedo è che la distribuzione / unione del flusso Git / Hub presuppone che una funzionalità sia sviluppata / testata / unita / distribuita alla volta - e spesso nella mia esperienza non è così. Se uniamo una funzionalità alla volta, vi è una maggiore possibilità di problemi di regressione, rilevata solo dopo che le funzionalità sono state unite al master e probabilmente in produzione.

È necessario un modo per testare più funzionalità, unire più funzionalità e distribuirne le stesse. Ho usato un "ramo bundle" (un ramo creato dal master con i rami delle funzionalità pronti per il test uniti in esso) che viene distribuito in qa / uat. Le correzioni durante uat si verificano solo nel ramo della funzione e quelle vengono ricongiunte al ramo del bundle. Dopo l'approvazione di una sottosezione del ramo del bundle, solo le funzioni approvate all'interno del bundle vengono richieste da pull al master e il ciclo è continuo.

Lo uso con Gitflow, ma medito di usarlo per il flusso GitHub. Le numerose funzionalità QA / UAT alla volta sembrano importanti. Un altro problema con il flusso di GitHub è che presuppone tutti gli sviluppatori sr, e non è sempre così.

Preferirei usare il flusso GitHub grazie alla sua semplicità. Con un bundle come funzionalità, penso che sarebbe meglio pronto. È possibile che il bundle sia simile al rilascio; tuttavia, sto ancora riflettendo su questo.

Un altro problema è che il processo di richiesta pull si verifica alla fine prima di unirsi al master; tuttavia, a volte si desidera rivedere il codice prima del test di qualità aziendale, quindi molto prima della fusione

— David Latty
fonte