Come mantenere correttamente sincronizzati i rami master e di sviluppo? GIT

Question

Mi piace fare sviluppo nel mio ramo di sviluppo, quindi unirmi al master quando sono pronto a spingere verso la produzione. Finché non commetto nulla per il master branch tutto procede senza intoppi.

Tuttavia, mi sono imbattuto in situazioni in cui ho commesso qualcosa sul ramo master che è in conflitto con qualcosa che è stato modificato nel ramo di sviluppo. Quando unisco il ramo di sviluppo al master, devo risolvere il conflitto. Non è un grosso problema, ma per assicurarsi che il ramo di sviluppo abbia tutto nel ramo principale (assicurandosi che lo sviluppo sia aggiornato) unisco il ramo master e alla fine devo risolvere nuovamente i conflitti.

Ho sentito dire che la rebasing è generalmente negativa, specialmente per le cose che stai pubblicizzando pubblicamente.

C'è un modo migliore per gestire questo tipo di installazione?

Answer 1

Il modo in cui lo farei è il contrario: master

1. merge a dev
2. merge dev a padroneggiare solo dopo che

risolvere tutti i conflitti, mentre la fusione.

Sebbene git sia eccezionale quando si tratta di unire e gestire i rami, non credo che ci sia un modo rapido per risolvere conflitti diversi dal lavoro manuale e noioso che utilizza strumenti di diff/merge a 3 vie.

Inoltre, aiuta a fare ciò che @cHao ha detto nella sua risposta qui sotto: unire spesso, unire piccole e si avranno a malapena grandi situazioni di unione dei conflitti.

Answer 2

da quello che posso dire, lo sviluppo è dove tutte le cose nuove succede. quindi, se questo è il caso, deviare dallo sviluppo (feature branch). lavorare su quel ramo. quando hai finito, basta unire lo sviluppo nel ramo delle funzionalità per assicurarti che sia aggiornato. quindi, controlla il ramo di sviluppo e unisci il tuo ramo di funzionalità in esso. dato che la gente del tuo team continua ad aggiungere funzionalità al ramo di sviluppo, a un certo punto il manager sarà come okay, we're releasing, quindi a quel punto fonderai il master in sviluppo (solo nel caso qualcuno abbia fatto un commit canaglia sul master) e poi il master di checkout e l'unione si sviluppano in esso.

speriamo che nessuno si impegni direttamente a sviluppare o padroneggiare. a quei due dovrebbero solo essere uniti. Inoltre, spero che tu abbia dei test per mentre stai sviluppando una funzionalità e dopo un'unione.

per quanto riguarda rebase è interessato, sì, dicono di non farlo dopo aver condiviso il ramo. quindi in questo caso non lo faresti sullo sviluppo del ramo perché è condiviso.

Answer 3

Unisci periodicamente dal master al tuo ramo di sviluppo e quindi risolvi eventuali conflitti. (Se lo fai regolarmente, i conflitti saranno in genere molto minori.)

Nel momento in cui avviene l'unione di nuovo con il master, lo sviluppo non dovrebbe affatto entrare in conflitto.

Answer 4

Penso che potresti avere solo alcune idee sbagliate qui che ti riguardano più di qualsiasi cosa che sia tecnicamente sbagliata.

In primo luogo, in genere non è necessario eseguire il commit direttamente sul ramo principale.Dal modo in cui hai descritto la tua situazione, non sono sicuro che ciò accada o no, ma se lo è, prova a non farlo.

Se si scopre che qualcosa non può essere unito in modo pulito in master, non provare a risolvere il problema sul master stesso. Invece, dovresti risolvere il problema sul ramo della funzione. Una volta risolto il problema, puoi quindi unirli perfettamente al master.

Per quanto riguarda rebase, è perfettamente utile utilizzare rebase fino a quando non si preme su un repository remoto. Una volta che hai inviato qualcosa a un repository remoto, non vuoi rebase, dato che stai rovinando la cronologia per qualcun altro, e git non può risolverlo per te. Quindi non temere rebase, solo sapere quando usarlo e quando non usarlo.

Un modo in cui potresti essere in grado di utilizzare il rebasing qui (anche in questo caso, supponendo che tu non abbia spinto il ramo in questione in remoto) per aiutare con il tuo problema è quello di prendere il ramo della funzione che non può essere unito in master e rebase su maestro. Questo ti obbligherà a risolvere il problema su quel ramo. Una volta risolto, l'unione in master dovrebbe essere banale (a meno che il master non sia stato nuovamente modificato nel frattempo) e si possa fondere in modo pulito in master.

Ci sono molti tutorial disponibili per git là fuori, e avranno anche degli esempi di codice per aiutare. Ecco uno dei più "classici", credo che il flusso di lavoro qui descritto funzioni bene. http://nvie.com/posts/a-successful-git-branching-model/

Si prega di notare che non sto approvando il set di script bash chiamato 'flusso git' che tenta di semi-automatizzare il flusso di lavoro lì (questi script non ha funzionato molto bene per noi quando li abbiamo provato), ma il flusso di lavoro in sé descritto qui funziona bene.

Answer 5

faccio

git checkout master 
git reset --hard dev 

Così master diventa esattamente dev. Basta non dimenticare di rebase dev se si desidera inviare l'aggiornamento rapido sul master.