remota - git pull origin master
git pull del maestro a la rama de desarrollo (2)
Tengo una rama llamada dmgr2 (desarrollo) y quiero extraerla de la rama maestra (sitio en vivo) e incorporar todos los cambios en mi rama de desarrollo. ¿Hay una mejor manera de hacer esto? Esto es lo que había planeado hacer, después de cometer cambios:
git checkout dmgr2
git pull origin master
esto debería atraer los cambios en vivo a mi rama de desarrollo, o tengo esto mal?
Los pasos que enumeró funcionarán, pero hay una forma más larga que le brinda más opciones:
git checkout dmgr2 # gets you "on branch dmgr2"
git fetch origin # gets you up to date with origin
git merge origin/master
El comando fetch se puede realizar en cualquier momento antes de la merge , es decir, puede intercambiar el orden de fetch y checkout, porque fetch simplemente va al control remoto nombrado ( origin ) y le dice: "dame todo lo que tengas que No lo hago ", es decir, todos se comprometen en todas las ramas. Se copian en su repositorio, pero se denomina origin/branch para cualquier rama llamada branch en el control remoto.
En este punto, puede usar cualquier visor ( git log , gitk , etc.) para ver "lo que tienen" que usted no tiene, y viceversa. A veces esto solo es útil para Warm Fuzzy Feelings ("ah, sí, eso es en realidad lo que quiero") y a veces es útil para cambiar estrategias por completo ("whoa, todavía no quiero esas cosas").
Finalmente, el comando de merge toma el compromiso dado, que puede nombrar como origin/master , y hace lo que sea necesario para traer ese compromiso y sus ancestros, a cualquier rama en la que se encuentre cuando ejecute la merge . Puede insertar --no-ff o --ff-only para evitar un avance rápido, o fusionar solo si el resultado es un avance rápido, si lo desea.
Cuando usas la secuencia:
git checkout dmgr2
git pull origin master
el comando pull indica a git que ejecute git fetch , y luego el equivalente moral de git merge origin/master . Así que esto es casi lo mismo que hacer los dos pasos a mano, pero hay algunas diferencias sutiles que probablemente no son demasiado preocupantes para ti. (En particular, el paso de fetch ejecutado por pull solo trae origin/master , y no actualiza la referencia en su repositorio: 1 cualquier confirmación nueva termina referida solo por la referencia especial FETCH_HEAD ).
Si usa el git fetch origin más explícito (entonces, opcionalmente, mire a su alrededor) y luego git merge origin/master , también puede actualizar su propio master local con el control remoto, con solo un fetch ejecutado a través de la red:
git fetch origin
git checkout master
git merge --ff-only origin/master
git checkout dmgr2
git merge --no-ff origin/master
por ejemplo.
1 Esta segunda parte ha sido modificada (digo "arreglado") en git 1.8.4, que ahora actualiza las referencias de "sucursales remotas" de manera oportunista. (Fue, como dicen las notas de la versión, una decisión de diseño deliberada para omitir la actualización, pero resulta que más gente prefiere que git la actualice. Si desea el antiguo SHA-1 de rama remota, se guardará de manera predeterminada en , y por lo tanto recuperable del reflog. Esto también habilita una nueva función git 1.9 / 2.0 para encontrar rebases en sentido ascendente).
Situación : trabajo en mi sucursal local, pero me encanta mantener las actualizaciones en la sucursal de desarrollo llamada dev .
Solución : Por lo general, prefiero hacer:
git fetch
git rebase origin/dev