Actualizar ramas de Git desde master

Básicamente tienes dos opciones:

1. Se fusionan. Eso es en realidad bastante simple, y una operación perfectamente local:

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

   Esto deja la historia exactamente como sucedió: Te bifurcaste de master, hiciste cambios en todas las ramas, y finalmente incorporaste los cambios de master en las tres ramas.

   git puede manejar esta situación muy bien, está diseñado para fusiona sucediendo en todas las direcciones, al mismo tiempo. Puedes confiar en que sea capaz de juntar todos los hilos correctamente. Simplemente no le importa si branch b1 fusiona master, o master fusiona b1, la confirmación de fusión se ve igual a git. La única diferencia es, qué rama termina apuntando a esta confirmación de fusión.

2. Usted rebase. Las personas con un SVN, o fondo similar encuentran esto más intuitivo. Los comandos son analógicos al caso merge:

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

   A la gente le gusta este enfoque porque conserva una historia lineal en todas las ramas. Sin embargo, esta historia lineal es una mentira, y usted debe ser consciente de que lo es. Considere este gráfico de confirmación:

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

   La fusión resulta en el verdadero historial:

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

   La rebase, sin embargo, le da esta historia:

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

   El punto es, que las confirmaciones E', F', y G' nunca existieron verdaderamente, y probablemente nunca han sido probados. Ni siquiera pueden compilar. En realidad, es bastante fácil crear confirmaciones sin sentido a través de un rebase, especialmente cuando los cambios en master son importante para el desarrollo en b1.

   La consecuencia de esto puede ser, que no se puede distinguir cuál de los tres commits E, F, y G realmente introdujo una regresión, disminuyendo el valor de git bisect.

   No estoy diciendo que no debas usar git rebase. Tiene sus usos. Pero cada vez que lo use, debe ser consciente del hecho de que está mintiendo sobre la historia. Y al menos deberías compilar y probar las nuevas confirmaciones.

git rebase master es la forma correcta de hacer esto. La fusión significaría que se crearía un commit para la fusión, mientras que el rebasing no.

Si ha estado trabajando en una rama de forma intermitente, o ha ocurrido mucho en otras ramas mientras ha estado trabajando en algo, es mejor cambiar la base de su rama a master. Esto mantiene la historia ordenada y hace que las cosas sean mucho más fáciles de seguir.

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

Notas:

• No rebases ramas en las que hayas colaborado con otros.
• Usted debe rebase en la rama a la que se fusionará que no siempre puede ser maestro.

Hay un capítulo sobre cambio de base en http://git-scm.com/book/ch3-6.html , y un montón de otros recursos por ahí en la web.

@cmaster hizo la respuesta mejor elaborada. En resumen:

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

No debe reescribir el historial de la rama en lugar de mantenerlos en estado real para futuras referencias. Mientras se fusiona con master, crea un commit extra, pero eso es barato. Las confirmaciones no cuestan.

Puedes fusionar, o puedes aplicar confirmaciones individuales a través de ramas usando git cherry-pick.

Para actualizar otras ramas como (copia de seguridad) con su copia de rama maestra. Puede seguir cualquier camino (rebase o merge)...

1. Hacer rebase (no habrá ningún commit extra hecho a la rama de backup).

2. Merge branches (habrá un commit adicional automáticamente a la rama de respaldo).

   Nota: Rebase no es más que establecer una nueva base (una nueva copia)

git checkout backup
git merge master
git push

(Repetir para otras ramas si alguna como backup2 y etc..,)

git checkout backup
git rebase master
git push

(Repetir para otras ramas si las hay como backup2 & etc..,)