GitHub Flow distribuire in produzione prima dell'unione con il master: una seconda funzione non sovrascriverà la prima?

Naviga le tue risposte
8

Nella comprensione di GitHub Flow, come visto qui , una funzionalità, dopo la revisione del codice, viene prima distribuita a produzione, quindi uniti in master.

Se esiste una seconda funzione derivata dallo stesso commit della prima funzione e anche questa viene distribuita direttamente in produzione, la produzione non conterrà più la prima funzione.

creato su learngitbranching.js.org

Una volta distribuito c2, come può essere distribuito c3 prima di fondersi con c2 o c4?

In che modo GitHub Flow gestisce questo problema?

Una soluzione ovvia potrebbe essere quella di richiedere che una funzionalità venga reimpostata sul master prima di essere distribuita alla produzione. Tuttavia, questo è soggetto all'errore umano. Se si dimentica di rebase, la produzione ora manca una funzionalità.

Apprezzerei soprattutto le risposte di coloro che hanno esperienza con GitHub Flow. Come fai a non avere questo problema?

    
posta DarkSigma 07.03.2017 - 02:05
fonte

2 risposte

1

Buone notizie! GitHub ha un articolo a riguardo!

Identificano tre misure di sicurezza:

  • Assicurati che superi i test. Si spera che faccia parte dei flussi di lavoro di implementazione più . Ma è una delle misure "di sicurezza" che sottolineano
  • "Blocca" la pipeline di distribuzione come necessario: quando un ramo di funzione viene distribuito o verificato in produzione, nessun altro può avviare una distribuzione.
  • Assicurati che ogni ramo distribuito contenga tutti i set di modifiche già implementati. Il modo in cui viene eseguito è un po 'più complicato. Ecco cosa dicono:

We use the GitHub API to verify this requirement. An endpoint on the github.com application exposes the SHA1 that is currently running in production. We submit this to the GitHub compare API to obtain the "merge base", or the common ancestor, of master and the production SHA1. We can then compare this to the branch that we're attempting to deploy to check that the branch is caught up. By using the common ancestor of master and production, code that only exists on a branch can be removed from production, and changes that have landed on master but haven't been deployed yet won't require branches to merge them in before deploying.

If it turns out the branch is behind, master gets merged into it automatically. We do this using the new ✨Merging API✨ that we're making available today. This merge starts a new CI build like any other push-style event, which starts a deploy when it passes.

L'API di fusione esegue fondamentalmente un'unione standard, ma lo fa sul lato server.

La tua soluzione probabilmente non ha bisogno di essere così sofisticata. Alla fine della giornata, hai solo bisogno di una ragionevole sicurezza che:

  • I test superano
  • Solo una persona distribuisce alla volta
  • Il master viene unito in rami di feature prima della distribuzione
risposta data 06.04.2017 - 16:39
fonte
0

Questo problema ti è successo o è una domanda teorica?

Git è "abbastanza intelligente" quando si fondono per spingere solo il codice modificato, se ci sono "problemi" ti darà un conflitto di fusione.

Ogni nuova funzione è basata sul ramo di sviluppo, non sulle funzionalità di base su altre funzionalità.

Una cosa che facciamo per ridurre al minimo i conflitti di unione è quella di unire spesso e prima di avviare una funzione, è sempre necessario eseguire lo sviluppo più recente. (non ci impegniamo mai a padroneggiare ma sempre a sviluppare un ramo, che verrà unito di tanto in tanto al ramo principale)

    
risposta data 07.03.2017 - 10:45
fonte

Leggi altre domande sui tag

Confronto della modellazione con l'ereditarietà rispetto alla composizione basata sui caratteri idiomatici Cosa fare dopo aver completato il progetto, ma prima di passare a quello successivo?