Leggendo di GitHub Flow , ho visto che uno dei suggerimenti principali dopo l'unione con il master è che dovremmo immediatamente distribuire, ma non ne capisco completamente la ragione. Non è possibile aspettare un paio di altre funzionalità? Cosa succederà se aspettiamo?
Fondamentalmente quello che sto cercando di chiedere qui è per esempi di come se non seguo il flusso potrebbe influenzare negativamente il mio software.
GitHub Flow "è un flusso di lavoro leggero e basato su filiali [...] in cui le distribuzioni vengono eseguite regolarmente." Pertanto, dovresti utilizzare questa procedura solo se:
Il processo suggerito per sviluppare una funzionalità è:
Quindi perché dovresti aspettare un paio di funzioni se puoi implementare immediatamente ogni nuova funzione? Se la funzione non è pronta, non dovresti distribuirla, tanto semplice. Mentre la funzione si sta preparando, la richiesta di pull rimane in attesa. Quando altre funzionalità vengono unite in master, il master deve essere unito al ramo della funzione (oppure, in base alle tue preferenze, il ramo della funzione deve essere ridefinito nel master corrente).
Questo è un processo molto leggero, quindi si presume che non sia necessario eseguire un QA completo prima del rilascio. Il processo di implementazione dovrebbe eseguire test automatici e, una volta che la funzione è attiva, è necessario convalidarla in produzione. Se c'è un problema, devi semplicemente ridistribuire lo stato attuale del ramo principale.
Secondo me questo processo è così leggero che è quasi privo di significato. Sembra essere più adatto per piccoli gruppi che lavorano su prodotti in fase iniziale in cui i fallimenti nella produzione sono accettabili. Non è difficile immaginare come un processo leggermente più severo sarebbe benvenuto. Ovviamente puoi adattare questo processo alle tue esigenze, ad es. introducendo un ruolo di manager di rilascio che decide quali funzionalità / richieste di pull vengono unite quando.
Ciò che il flusso di lavoro di GitHub dimostra molto bene è come GitHub può integrare il prodotto in tale processo, ad es. come piattaforma per discussioni su una richiesta di pull. Puoi trovare materiale simile dai concorrenti di GitHub:
Gitlab Flow e Gitlab Workflow sono documenti più approfonditi e presentano diverse possibilità piuttosto che la prescrizione di un particolare processo. Menzionano e contrastano il flusso di Git e il flusso di GitHub con altri approcci: "In reazione al flusso git è stata dettagliata una semplice alternativa, flusso GitHub. [...] Ma questo flusso lascia ancora molte domande senza risposta riguardo a implementazioni, ambienti, rilasci e integrazioni con problemi. "Ma tra tutte queste possibilità, non offrono un chiaro processo alternativo.
Trovo le esercitazioni Git di Atlassian (Bitbucket) molto più sfumate e approfondite, e non come vendite. Nel flusso di lavoro Simple Git presentano gli stessi concetti del flusso GitHub, ma si concentrano su Git operazioni piuttosto che il loro prodotto. In Git Workflow: confronto dei flussi di lavoro , scrivono:
There is no one size fits all Git workflow. […]
The longer a branch lives separate from the production branch, the higher the risk for merge conflicts and deployment challenges. Short-lived branches promote cleaner merges and deploys. […]
A workflow should complement your business’s software development release cycle. […]
Questo documento vale la pena di essere letto perché illustra come diversi flussi di lavoro sono orientati verso obiettivi diversi, e in particolare come questi obiettivi influenzano il ruolo del ramo master .