Le funzionalità distribuite con GitHub Flow scompaiono dalla produzione?

Question

Le funzionalità distribuite con GitHub Flow scompaiono dalla produzione?

#1 da (1 voti)

1

Sto cercando di comprendere meglio i flussi di lavoro Git e di leggere questo post del blog . Cosa succede dopo l'unione in master se un'altra funzione è in attesa di distribuzione?

La distribuzione da master viene posticipata e la funzionalità viene distribuita per prima.

La funzione deve attendere una distribuzione da master prima di poter bloccare l'applicazione.

Ilpostdelblogdice:

Onceacommitonmasterhasbeendeployedtoproduction,itshouldneverbe“removed”fromproductionbydeployingabranchthatdoesn’thavethatcommitinityet.

Quantosoprasuggeriscechemasterpotrebbeaverecommitchenonsonoancorastatidistribuiti.

Anendpointonthegithub.comapplicationexposestheSHA1thatiscurrentlyrunninginproduction.WesubmitthistotheGitHubcompareAPItoobtainthe“mergebase”,orthecommonancestor,ofmasterandtheproductionSHA1.Wecanthencomparethistothebranchthatwe’reattemptingtodeploytocheckthatthebranchiscaughtup.Byusingthecommonancestorofmasterandproduction,codethatonlyexistsonabranchcanberemovedfromproduction,andchangesthathavelandedonmasterbuthaven’tbeendeployedyetwon’trequirebranchestomergetheminbeforedeploying.

Seledistribuzionida%co_dehannosempreavutolaprecedenza,la"base di unione" sarebbe sempre master , quindi, di nuovo, suggerisce che ci possono essere commit su HEAD che non sono stati distribuiti.

Entrambi questi elementi mi inducono a ritenere che le distribuzioni da commit su master possano essere ritardate mentre le funzionalità aggiuntive vengono implementate / testate prima sulla produzione. In questo caso, entrambe le funzioni ( master e 2 ) vengono visualizzate dal vivo per 15 minuti e quindi scompaiono temporaneamente finché non vengono ridistribuite da un 3 commit?

Che cosa succede se le caratteristiche master e 2 sono in conflitto?

Se sono completamente frainteso, qualcuno potrebbe dare un esempio di cosa succederebbe se le funzioni 3 e 2 fossero in conflitto tra loro e si tentasse di distribuirle nello stesso momento?

git github

posta Ryan J 29.04.2018 - 07:05

fonte

1 risposta

Leggi altre domande sui tag git github

Accesso alle proprietà delle classi composite senza interrompere l'incapsulamento Riscrive un'applicazione desktop vecchia e danneggiata tramite un'API locale

score 1 · Accepted Answer

Nel GitHub Flow , un ramo viene implementato prima è fuso in master . Pertanto, master rappresenta la cronologia delle versioni implementate correttamente.

Nell'articolo che hai collegato, GitHub l'azienda spiega come risolve due enormi problemi con questo flusso di lavoro:

Come posso evitare che due rami vengano distribuiti contemporaneamente?
Come posso impedire la distribuzione di un ramo se non è aggiornato con il master?

La soluzione a cui arrivano utilizza strumenti esterni, non alcuna funzionalità Git. I loro strumenti di implementazione possono bloccare le distribuzioni per un ramo, in modo da prevenire le distribuzioni in conflitto.

La loro soluzione per le filiali distribuite è più complessa, perché sembrano consentire l'unione in master senza averle prima distribuite. Invece, a quanto pare hanno un concetto di un ramo di produzione per i commit che sono stati distribuiti. Un ramo non deve rimuovere i commit sul master che sono stati distribuiti, cioè qualsiasi ramo che deve essere distribuito deve contenere la base di unione della produzione e del master correnti. Presumo che il ramo che viene distribuito diventi il ramo di produzione? Il loro post sul blog non è completamente chiaro.

Nei tuoi scenari, una volta unito il primo ramo di funzionalità / il ramo di produzione corrente (creando il commit di fusione n. 4), la base di unione di master e produzione è l'HEAD del ramo di produzione (n. 2). Pertanto, l'altro ramo può essere distribuito solo se contiene il n. 2, ad esempio unendo o rebasando il n. 4 prima di avviare la distribuzione. Quindi il tuo secondo diagramma sembra essere più vicino al loro approccio. Si noti che non è necessario distribuire immediatamente il merge commit # 4, poiché non contiene modifiche relative al ramo di produzione.

Tuttavia, nessuno di questi dettagli è fondamentale per GitHub Flow e si può certamente fare una distribuzione continua senza GitHub Flow. Ad esempio, passare un giocattolo di peluche come una serratura può essere una soluzione non tecnica efficace al problema del blocco, almeno per i piccoli team co-localizzati. La distribuzione da master anziché da feature branch evita completamente il problema di regressione. Rende anche più difficile la sperimentazione in produzione, che potrebbe effettivamente essere una caratteristica?

Quindi per favore non copiare alcun flusso di lavoro solo perché qualcuno famoso ha sviluppato abbastanza strumenti interni per rendere questo flusso di lavoro non schifo. Invece, fai qualcosa che abbia senso nelle tue circostanze e risolvi i tuoi problemi.