Aggiorna i rami Git dal master

Sono nuovo di Git, e ora sono in questa situazione:

• Ho quattro rami (master, b1, b2 e b3).
• Dopo aver lavorato su b1-b3, mi sono reso conto che ho qualcosa da cambiare su Branch Master che dovrebbe essere in tutti gli altri rami.
• Ho cambiato quello di cui avevo bisogno mastere ... ecco il mio problema:

Come posso aggiornare tutti gli altri rami con il mastercodice filiale?

Hai due opzioni:

Il primo è un'unione, ma questo crea un ulteriore commit per l'unione.

Dai un'occhiata a ciascun ramo:

git checkout b1

Quindi unisci:

git merge origin/master

Quindi premere:

git push origin b1

In alternativa, puoi fare un rebase:

git fetch
git rebase origin/master

Hai sostanzialmente due opzioni:

1. Ti unisci. In realtà è abbastanza semplice e un'operazione perfettamente locale:

   git checkout b1
   git merge master
   # repeat for b2 and b3
   

   Questo lascia la storia esattamente come è successo: hai biforcato dal maestro, hai apportato modifiche a tutti i rami e infine hai incorporato i cambiamenti dal maestro in tutti e tre i rami.

   gitè in grado di gestire questa situazione davvero bene, è progettato per le fusioni che avvengono in tutte le direzioni, allo stesso tempo. Puoi fidarti di essere in grado di riunire correttamente tutti i thread. Semplicemente non importa se il ramo b1si fonde mastero si masterfonde b1, il commit di unione sembra lo stesso per git. L'unica differenza è, quale ramo finisce per puntare a questo commit di unione.

2. Ti rebase. Le persone con un SVN o un background simile lo trovano più intuitivo. I comandi sono analoghi al caso merge:

   git checkout b1
   git rebase master
   # repeat for b2 and b3
   

   Alla gente piace questo approccio perché mantiene una storia lineare in tutti i settori. Tuttavia, questa storia lineare è una bugia e dovresti essere consapevole che lo è. Considera questo grafico di commit:

   A --- B --- C --- D <-- master
    \
     \-- E --- F --- G <-- b1
   

   La fusione risulta nella vera storia:

   A --- B --- C --- D <-- master
    \                 \
     \-- E --- F --- G +-- H <-- b1
   

   Il rebase, tuttavia, ti dà questa storia:

   A --- B --- C --- D <-- master
                      \
                       \-- E' --- F' --- G' <-- b1
   

   Il punto è che gli impegni E', F'e G'mai realmente esistiti, e probabilmente non sono mai stati testati. Non possono nemmeno compilare. In realtà è abbastanza facile creare commit senza senso tramite un rebase, specialmente quando i cambiamenti mastersono importanti per lo sviluppo in b1.

   La conseguenza di questo può essere, che non è possibile distinguere quale delle tre commit E, Fe Gin realtà ha introdotto una regressione, diminuendo il valore di git bisect.

   Non sto dicendo che non dovresti usare git rebase. Ha i suoi usi. Ma ogni volta che lo usi, devi essere consapevole del fatto che stai mentendo sulla storia. E dovresti almeno compilare test i nuovi commit.

git rebase masterè il modo corretto di farlo. La fusione significherebbe la creazione di un commit per l'unione, mentre la rifasatura no.

Se hai lavorato su un ramo on-e-off, o sono successe molte cose in altri rami mentre hai lavorato su qualcosa, è meglio convertire il tuo ramo in master. Ciò mantiene in ordine la storia e rende le cose molto più facili da seguire.

git checkout master
git pull
git checkout local_branch_name
git rebase master
git push --force # force required if you've already pushed

Appunti:

• Non modificare i rami su cui hai collaborato con altri.
• Dovresti rifare il riferimento al ramo in cui ti unirai, che potrebbe non essere sempre padrone.

C'è un capitolo sulla riformulazione su http://git-scm.com/book/ch3-6.html e un sacco di altre risorse sul web.

@cmaster ha fatto la risposta più elaborata. In breve:

git checkout master #
git pull # update local master from remote master
git checkout <your_branch>
git merge master # solve merge conflicts if you have`

Non è necessario riscrivere la cronologia delle filiali invece di mantenerli nello stato effettivo per riferimenti futuri. Mentre si fonde con master, crea un ulteriore commit ma è economico. Impegni non costa.

Per aggiornare altri rami come (backup) con la copia del ramo principale. Puoi seguire in entrambi i modi (rebase o unione) ...

1. Esegui rebase (non verrà eseguito alcun commit aggiuntivo nel ramo di backup).

2. Unisci i rami (verrà eseguito automaticamente un ulteriore commit nel ramo di backup).

   Nota: Rebase non è altro che stabilire una nuova base (una nuova copia)

git checkout backup
git merge master
git push

(Ripetere l'operazione per altri rami, ad esempio backup2 e così via, ecc.)

git checkout backup
git rebase master
git push

(Ripetere l'operazione per altri rami, ad esempio backup2 e così via, ecc.)

È possibile unire o applicare singoli commit tra i rami usando git cherry-pick .

Esistono due opzioni per questo problema.

1) git rebase

2) git merge

Solo diff con sopra entrambi in caso di unione, avrà un impegno extra nella cronologia

1) git checkout branch (b1, b2, b3)

2) git rebase origin / master (In caso di conflitti risolti localmente facendo git rebase --continua)

3) git push

In alternativa, l'opzione git merge è di moda simile

1) git checkout "your_branch" (b1, b2, b3)

2) git merge master

3) git push

per aggiornare il tuo ramo dal master:

  git checkout master
  git pull
  git checkout your_branch
  git merge master