git con rami di sviluppo, produzione e produzione

Questo articolo sembra interessante, ma sono abbastanza sicuro che i diagrammi siano sbagliati. http://guides.beanstalkapp.com/version-control/branching-best-practices.html git con rami di sviluppo, produzione e produzione

Non dovrebbe essere DEVELOPMENT>STAGING>PRODUCTION?

Unisce deve fluire in una sola direzione: da funzionalità e bug-fix fatto nella propria filiale o in fase di sviluppo nella messa in scena per il test. Una volta testato, è possibile unire le modifiche dallo sviluppo alla produzione .

Qui mi sento un po 'confuso. Quindi unisco Staging in Master o Master in Staging?

Sto usando un client chiamato SmartGit e mi confondo su questo punto. Normalmente creo un ramo per una funzione, ci impegno, poi passa a master e lo unisco al ramo (avanti). Quindi, in questo nuovo flusso di lavoro con Staging and Production, creo questi due rami extra, quindi creo un branch da master (aka dev) per la mia funzione. Impegnarsi su di esso, quindi passare a Staging e unire (avanti) al mio ramo delle funzionalità? Suona corretto?

In realtà ciò che ha reso questo così confuso è che la gente fagiolo magico stanno dietro il loro uso molto non standard di messa in scena (si tratta prima di sviluppo nel loro schema, e non è un errore! https://twitter.com/Beanstalkapp/status/306129447885631488

Avere ha deciso di dimenticare fagiolo magico e solo con Github.

da quando ho postato questo, la gente fagiolo magico preso il mio suggerimento e rinominato loro stadi, ora chiamando sviluppo "Stabile".

fonte

2013-02-25 Max Hodges

Si desidera unire le correzioni dalla gestione temporanea alla produzione. La fusione con la messa in scena allo scopo di test e l'unione dello sviluppo alla produzione al termine del test lascia aperta la possibilità di ulteriori lavori sullo sviluppo che si uniscono alla produzione che non è mai stata unita alla gestione temporanea. – wadesworld

I workflow di branching classici non sono facili da applicare a Git in quanto i rami in Git sono molto più leggeri. Sono solo indicatori di (singoli) commessi all'interno della storia che possono diramarsi in molte direzioni. Questo è il motivo per cui è difficile vedere i rami come una "linea" di sviluppo separato (questo vale anche per i diagrammi di "Un modello di successo di Git Branching"). – poke

sì, non è esattamente il nuoto delle corsie. Ma la mia domanda è più specificatamente: passare a Staging e unire a dev, o viceversa? Sono nuovo di git e confuso su questo. Forse dovrei rivolgere la domanda direttamente ai creatori di SmartGit, il mio client Windows Git. –

Il processo di riflessione qui è che trascorri la maggior parte del tempo in development. Quando sei in fase di sviluppo, crei un ramo feature (fuori da development), completa la funzione e quindi unisci nuovamente in development. Questo può quindi essere aggiunto alla versione di produzione finale mediante la fusione in production.

Vedere A Successful Git Branching Model per ulteriori dettagli su questo approccio.

fonte

2013-02-25 17:02:59 eykanal

+14

+1 per "Un modello di ramificazione di Git riuscito". Questo è diventato fondamentalmente lo standard per quanto riguarda i workflow git. –

"Un modello di branching Git di successo" è un po 'complesso per i progetti più piccoli con solo poche persone coinvolte. Preferisco il metodo più semplice, in cui lo sviluppo è fatto nel ramo principale e le versioni stabili sono marcate nel ramo principale e hanno il loro ramo stabile per le patch, se necessario. Vedi http://stackoverflow.com/questions/14858075/set-the-develop-branch-as-the-default-for-a-pull-request/14858295#14858295 e http://scottchacon.com/2011/08 /31/github-flow.html –

grazie @JosefKufner L'articolo del flusso github è stato molto utile –

Lo rendiamo diverso, IMHO più semplice: nel master stiamo lavorando alla prossima versione principale.

Ogni caratteristica più grande ottiene il proprio ramo (derivato dal master) e sarà ridefinita (+ force pushed) in cima al master regolarmente dallo sviluppatore (il rebasing funziona bene solo se un singolo sviluppatore lavora su questa funzione). Se la funzione è terminata, sarà nuovamente ridefinita su master e quindi il master verrà inoltrato rapidamente all'ultima funzione commessa. Per evitare il ribasso/spinta forzata si può anche unire regolarmente le modifiche principali al ramo della funzione e, se è finito, unire il ramo della caratteristica in master (fusione normale o unione di squash). Ma IMHO rende questo aspetto meno chiaro e rende molto più difficile riordinare/ripulire i commit.

Se è in arrivo una nuova versione, creiamo un ramo secondario fuori dal livello principale, ad es. release-5 dove vengono corretti solo errori.

fonte

2013-02-25 20:16:17 Mot

Non ho idea di cosa significhi. –

Che cosa non capisci? – Mot

una delle cose migliori di git è che puoi cambiare il flusso di lavoro che funziona meglio per te ..Io uso la maggior parte delle volte il http://nvie.com/posts/a-successful-git-branching-model/

fonte

2013-02-28 23:50:47 JohnNY

In realtà ciò che ha reso questo così confuso è il fatto che le persone del fagiolo magico stanno dietro il loro uso non standard di Staging (viene prima dello sviluppo nel loro schema, e non è un errore

https://twitter.com/Beanstalkapp/status/306129447885631488

fonte

2013-03-13 19:12:16

da a post on my blog:!

Il flusso di lavoro "gitflow" dal nvie ha due problemi: è confusamente cha aumenta il significato del ramo "master", e non è chiaro che lo giustifichi il costo di un ramo aggiuntivo di lunga durata. Entrambi i problemi potrebbero essere risolti da [...]

fonte

2017-01-03 17:57:25

git con rami di sviluppo, produzione e produzione

risposta

Problemi correlati