Tirando le modifiche dal master al mio ramo di lavoro?

Ho visto le filiali sviluppatore utilizzate in due scenari principali:

1. La comunità open-source, in cui questi rami sono effettivamente fork del repository, in modo che i responsabili del progetto possano bloccare l'accesso al repository principale e richiedere l'integrazione tramite richieste pull. Ciò rende la vita più difficile per i contributori, ma molto più semplice per i manutentori, che ovviamente è esattamente il punto, e questo è un modello di grande successo su GitHub.

2. Squadre e organizzazioni che non hanno un'integrazione continua e un track record di instabilità nelle loro implementazioni o, peggio, instabilità nelle loro build. Queste squadre generalmente cercano di utilizzare le filiali degli sviluppatori come modo per proteggere la stabilità della linea principale, e il risultato è - tipicamente - un periodo di fusione lungo e molto doloroso prima dell'uscita, seguito da un periodo di stabilizzazione ancora più lungo e più doloroso, che a volte non succede fino a dopo la versione.

Non voglio che questo sia un accenno sul motivo per cui hai bisogno di CI, ma è chiaro dalla tua domanda che conosci non stai integrando le tue modifiche abbastanza spesso, quindi IMO non ha senso nel ballare intorno al problema.

A meno che non si stia effettivamente lavorando in un team distribuito geograficamente con la necessità di "passare" i cambiamenti da sviluppatori esterni, il modello di ramo per sviluppatore non ha molto senso. In particolare, non ha senso con git, perché ogni sviluppatore già ha tecnicamente il proprio repository. La maggior parte delle organizzazioni dovrebbe essere integrata molto frequentemente, come in, più volte al giorno.

Attualmente faccio parte di un gruppo di circa 35 contributori divisi in 4 squadre separate, la maggior parte delle persone effettua il check-in almeno 2-3 volte al giorno, alcune persone 10-15 volte; è raro vedere le costruzioni rotte ed estremamente rare per loro di rimanere rotti per più di qualche minuto. Git gestisce le fusioni in modo estremamente semplice il più delle volte in cui i rami degli sviluppatori remoti sono solo inutili. Basta tirare, unire localmente ed eseguire test di commit prima di spingere, è semplice.

Se assolutamente deve rinviare l'integrazione per proteggere la stabilità del ramo master, il tipico modello comprovato è di usare un ramo instabile - a volte chiamato < em> ramo di sviluppo , come descritto in un riuscito modello di branching Git . Se gli sviluppatori non riescono a fondersi con successo in questo ramo (che ha solo bisogno di build , non eseguire in modo impeccabile) almeno una volta al giorno, allora si ha un problema di qualità / disciplina e non un problema di controllo di revisione; coprirlo con le filiali di sviluppatori non integrati non fa altro che rimandare il problema e, così facendo, rende l'unione molto più dolorosa e instabile di quanto sia realmente necessario.

I rami di funzionalità non sono i peggiori, ma pochi progetti di IMO sono effettivamente abbastanza grandi da giustificarli; se il tuo progetto è molto ampio (vale a dire un sacco di funzionalità su cui lavorare contemporaneamente), vedrai risultati migliori dividendoli in componenti autonomi separati rispetto a quelli che dovrai affrontare per risolvere il problema con il controllo del codice sorgente.

Puoi ignorare questo consiglio se vuoi, e molti team lo fanno, ma uno dei motivi per cui il modello di ramificazione collegato sopra è così popolare e di successo è che è progettato per funzionare con con integrazione continua, non contro di esso.

Nel tuo ramo di lavoro se vai:

git commit -am "Committing changes before merge"
git merge master

puoi anche unire dal ramo degli altri sviluppatori

git checkout dev-A
git merge dev-B

Ciò che farà è unire le modifiche nel master a il tuo ramo di sviluppo.

Se dev-A e dev-B sono rami diversi per progetti diversi, allora quello che @scaryrawr ha risposto sarebbe stato il migliore.

Ma se dev-A e dev-B sono in realtà esattamente lo stesso codice (stesso progetto), allora un'alternativa sarebbe che entrambi funzionano su uno dei rami. Ad esempio, crei un master di diramazione chiamato "devWork". Entrambi esegui il checkout di devWork, lavoraci su, commetti e apporta modifiche. Le modifiche forzate non sarebbero sul master ma in devWork, quindi gli altri utenti del ramo devono semplicemente eseguire un PULL localmente per ottenere modifiche push.

Potresti quindi seguire i metodi standard per portare a termine il lavoro su devWork su Master ecc.