La tendenza del ramo "sviluppo" sta andando via

Viene dalla mentalità CI in cui è presente l'integrazione più volte al giorno.

Ci sono pro e contro di entrambi.

Nel nostro team abbiamo abbandonato anche il ramo di sviluppo dal momento che ritenevamo che non fornisse ulteriori vantaggi ma alcuni inconvenienti. Abbiamo configurato il nostro software CI (Teamcity) per compensare gli svantaggi:

1. Abilita la distribuzione di un commit specifico. In altre parole: non distribuiamo un ramo. Distribuiamo un commit.
2. Siamo in grado di distribuire master o diramazioni che iniziano con un hotfix / prefisso.

Il motivo per cui questo funziona è perché tutte le richieste pull contengono codice potenzialmente rilasciabile, ma questo non significa che distribuiremo tutte le commit nel master.

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

Un ramo in via di sviluppo è più importante se il tuo processo di rilascio è complesso e hai bisogno di candidati a rilascio definitivo.

Ad esempio, immagina di scrivere software che è il firmware delle auto. Questo è ... non banale da correggere ed è probabile che qualsiasi versione disponga di un set completo di test di integrazione non-CI / esecuzione su hardware reale.

In questo caso potrebbe avere più senso isolare un "candidato alla release" in un ramo non master (come "sviluppo"). Ciò consente al tuo team che esegue questi test di avere un ramo per unire le caratteristiche in.

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

Tuttavia, nota che:

• Molti (più?) progetti su github non hanno questo tipo di vincolo
• Un "master" principale ha lo stesso scopo
• Un flusso di lavoro di "make a PR vs master" è molto più universale di "crea un PR contro un ramo che non conosci immediatamente su questo repo"

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

1. Designare "master" come release di produzione e svilupparsi in un ramo "sviluppo".

2. Sviluppare in "master" e disporre di un ramo con un nome diverso per rilasci di produzione stabili. Ciò ha ancora più senso se il tuo progetto ha più rami di rilascio alla volta (ad esempio, quello corrente preferito è Release-1.8, ma stai ancora mantenendo il Release-1.7).

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

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

Se un bug critico viene rilevato in produzione in un momento in cui il master non può essere rilasciato, allora è abbastanza semplice eseguire il checkout del 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, il master è cambiato dall'ultima versione, ma non molto significativamente, quindi possiamo semplicemente fare una nuova release dal master che ha la soluzione. Aiuta comunque a fare versioni molto frequenti.

If developers are working on feature branches, and then merging those into master when they're done, that means there's a period of time where features/fixes are being merged into master and the master branch is actually newer than production.

...

Imagine if people are merging straight into master, and a bug is reported in production that becomes difficult to fix because the master branch codebase has changed significantly.

Questo non è Github Flow.

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

Deploy

Once your pull request has been reviewed and the branch passes your tests, you can deploy your changes to verify them in production. If your branch causes issues, you can roll it back by deploying the existing master into production.

Merge

Now that your changes have been verified in production, it is time to merge your code into the master branch.

(Enfasi mia)

In altre parole, master non sarà mai prima della produzione. Allo stesso modo, master sarà sempre in uno stato stabile e rilasciabile (oltre a bug non scoperti), poiché tutto viene rivisto, testato e distribuito alla produzione prima che viene unita a master .

Il problema che vedo è che Git / Hub flow deploy / merge presuppone che una funzione sia stata sviluppata / testata / unita / dispiegata alla volta - e spesso nella mia esperienza questo non è il caso. Se uniamo una funzione alla volta, c'è una maggiore possibilità di problemi di regressione, che si trovano solo dopo che le funzioni sono state unite al master e possibilmente in produzione.

Ci deve essere un modo per testare più funzionalità, unire più funzionalità e distribuire le stesse. Ho utilizzato un "bundle branch" (un branch creato da master con branch di funzionalità pronti per il test uniti) che viene distribuito a qa / uat. Le correzioni durante uat avvengono solo sul ramo della funzione, e quelle vengono nuovamente riunite al ramo del pacchetto. Dopo che una sottosezione del ramo del bundle è stata approvata, solo le funzionalità approvate all'interno del bundle ottengono pull-richiesto per il master - e il ciclo è continuo.

Lo uso con Gitflow, ma sto pensando di usarlo per il flusso GitHub. Il problema di QA / UAT in un momento sembra importante. Un altro problema con il flusso di GitHub è che presuppone tutti gli sviluppatori sr, e non è sempre il caso.

Preferirei usare il flusso GitHub a causa della sua semplificazione. Con una funzionalità simile al bundle, penso che sarebbe meglio pronto. È possibile che il pacchetto sia simile al rilascio; tuttavia, sto ancora riflettendo su questo pure.

Un altro problema è che il processo di richiesta di pull si verifica alla fine prima di unire a master; tuttavia, a volte si desidera eseguire la revisione del codice prima del test di business qa, quindi ben prima dell'unione