Strategia di ramificazione di GitFlow, ma senza il ramo di sviluppo

Ci sono alcuni svantaggi, non vedo molti benefici.

Non sei sicuro di come stai evitando la necessità di unirmi al master, a meno che il master non risponda alla "versione più recente rilasciata"

Il principale inconveniente che vedo è che stai ricevendo un comportamento "in via di sviluppo", ma cambiando il nome del tuo "svilupparsi" in ogni sprint e facendo in modo che l'elemento della configurazione punti a un altro ramo ogni scatto.

Il secondo più grande svantaggio a mio parere, sta correggendo i bug. Quando si risolvono i bug in una versione precedente, è necessario portarli nella versione corrente (e probabilmente in alcune versioni intermedie, se i clienti utilizzano versioni diverse). Hai reso questo processo più difficile con la tua struttura di filiali, potenzialmente gestendo molte più di 3 filiali di integrazione.

Se stai cercando di evitare la fusione, non otterrai i vantaggi della ramificazione.

Mi sembra che tu stia ancora facendo GitFlow, stai solo armeggiando con la denominazione del ramo di sviluppo.

Ora c'è un grosso problema qui. Non tanto con la ridenominazione / rebranching ma con la tua scelta del nome.

Vuoi nominare il ramo con la versione della versione. Tuttavia, non puoi conoscere la versione di rilascio prima di arrivare al punto di rilascio.

es .:

• Chiama il tuo ramo release_1.0.0.2 ma prima che lo completi devi fare una correzione a caldo! ora la tua versione sarà 1.0.0.3

• OK, decidi di lasciare il numero di build e chiama il ramo release_1.0.1.x ma poi ti rendi conto che una delle tue funzionalità introduce un cambiamento radicale! ora vuoi cambiarlo in release_1.2.0.x

• Si avvia una funzionalità in release_1.1.x.x ma non è finita in tempo per la fine dello sprint. ora devi fonderlo in release_1.2.x.x

Tutto sommato è meglio ramificare i rami di rilascio dal master quando li rilasci piuttosto che in anticipo e utilizzare elementi come i numeri di build generati automaticamente e il tagging per etichettare le versioni di rilascio nel controllo git / source

Posso comprendere appieno che non vuoi mantenere il ramo di sviluppo. È noioso mantenere sia il master che lo sviluppo. Abbiamo anche abbandonato l'uso di un ramo di sviluppo. Ci assicuriamo che il master sia sempre in uno stato funzionante. Solo il codice potenzialmente relesable va in master. Lo realizziamo utilizzando i rami delle caratteristiche.

Di solito ci stavamo liberando dal master ma abbiamo avuto alcuni problemi minori nell'ultima release in cui non era chiaro quando il "cut-off" era il risultato della mancata verifica del rilascio, come avremmo voluto.

In futuro stiamo parlando di rilasciare un ramo di rilascio invece di un master. Oggi abbiamo questi rami di rilascio, ma oggi li uniamo per padroneggiare prima di rilasciarli che non è ottimale.

Immediatamente dopo un rilascio, il ramo di rilascio verrà unito al master.

Il flusso che descrivi sembra una configurazione ideale e non vedo grossi inconvenienti. In futuro probabilmente stiamo facendo qualcosa di simile.

Credo che il tuo stile di ramificazione debba essere basato sulla tua strategia di rilascio:

• Sviluppo prodotto / libreria
• Rilasci basati su Sprint
• Implementazione continua

Storicamente, mi sono concentrato sullo sviluppo di prodotti e librerie. In quel mondo, di solito hai più versioni in uso simultaneo e l'implementazione potrebbe essere notevolmente diversa tra le versioni, in modo che le correzioni di bug per una versione non possano essere semplicemente unite in un'altra versione. Per supportare questo, utilizzo la seguente struttura:

• Branche delle feature: singole unità di lavoro, che iniziano come parte di una release ma potrebbero o meno finire in quella versione .
• Un ramo di rilascio, che riceve commit schiacciati di funzionalità (e viene regolarmente unito ai rami delle funzionalità per ridurre al minimo i conflitti).
• Master, che contiene la versione più recente della codebase.

La chiave qui è che un ramo Release continuerà ad essere attivo dopo essere stato unito al master e ricevere modifiche che potrebbero o meno essere presenti altrove. Ad esempio, mentre lavori sul ramo rel_1_9 , potresti fare una correzione su rel_1_2 e taggare quel bugfix con rel_1_2_7 .

In questo approccio, in realtà non c'è bisogno di Master: puoi creare un nuovo ramo di rilascio dal tag di rilascio e impostarlo come ramo predefinito. Ma ad alcune persone piace avere master quindi ...

L'ambiente alternativo è quello in cui si fanno periodici rilasci, ma non si ritorna mai a versioni precedenti (ad esempio, una tipica app in hosting). In tal caso, ritengo che la strategia di ramificazione dipenda dal fatto che si pratichi la distribuzione continua o gli sprint.

Per gli sprint, Develop è utile come un ramo di integrazione: tutto il nuovo lavoro viene incorporato in esso dai rami Feature, ma non viene unito a Master fino allo sprint. Durante lo sprint, le hot-fix possono essere commesse su Master e quindi unite in Develop. Non c'è davvero alcun motivo per creare filiali separate per ogni versione; se il ramo non viene mai toccato dopo l'unione, è semanticamente identico a un tag.

E se stai facendo una distribuzione continua, ti consiglio di mantenere i rami Feature e Master e di eliminare lo sviluppo. Se hai più sviluppatori che uniscono il loro lavoro a Develop prima di Master, avrà una situazione in cui le modifiche indesiderate verranno unite e implementate.

Autopromozione senza vergogna: link

Nella mia azienda, usiamo un approccio simile (nel senso che abbiamo release rami creati dopo ogni sprint, ma invece di develop , abbiamo in qualche modo deciso di fare a meno di master ). Penso che la logica sia di mantenere le pubblicazioni mantenute "per sempre".

Questa strategia ha senso se il tuo prodotto verrà installato su più macchine e non avrai il controllo su quando queste installazioni eseguiranno l'aggiornamento a una versione diversa. Se segui GitFlow, le versioni precedenti sono raggiungibili, ma non sono così facili da correggere, specialmente dopo aver unito le nuove versioni in master . Tali prodotti sarebbero ad es. applicazioni desktop o sistemi stand-alone.

Questa strategia ha molto meno senso se il tuo prodotto è un servizio e hai il controllo completo su quando viene aggiornato: tu installi la versione più recente nei tuoi server, ei clienti non possono scegliere con quale versione parlano. Qualsiasi servizio web è un esempio.

In breve, entrambe le strategie sono fattibili, entrambe possono avere lati positivi e negativi; Penso che il grado di controllo sui rilasci che hai sia quello che dovrebbe guidare la tua decisione.