Cómo "git pull" desde master a la rama de desarrollo
Tengo una rama llamada "dmgr2" en 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 realizar cambios:
git checkout dmgr2
git pull origin master
Esto debería llevar los cambios en vivo a mi rama de desarrollo, ¿o me equivoqué?
Los pasos que enumeró funcionarán, pero hay un camino más largo 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 fetchcomando se puede realizar en cualquier punto antes del merge, es decir, puedes intercambiar el orden de búsqueda y pago, porque fetchsimplemente vas al control remoto nombrado ( origin) y le dice: "dame todo lo que tienes y yo no". ", es decir, todos los compromisos en todas las ramas. Se copian en su repositorio, pero reciben el nombre origin/branchde cualquier rama nombrada branchen el control remoto.
En este punto puedes utilizar cualquier visor ( git log, gitk, etc) para ver "lo que tienen" que tú no tienes, y viceversa. A veces esto sólo es útil para sentimientos cálidos y difusos ("ah, sí, eso es de hecho lo que quiero") y a veces es útil para cambiar estrategias por completo ("vaya, todavía no quiero ESAS cosas").
Finalmente, el mergecomando toma la confirmación dada, que puede nombrar como origin/master, y hace lo que sea necesario para incorporar esa confirmación y sus antepasados, a cualquier rama en la que se encuentre cuando ejecuta el archivo merge. Puede insertar --no-ffo --ff-onlypara 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 pullcomando le indica a git que se ejecute git fetchy luego el equivalente moral de git merge origin/master. Esto es casi lo mismo que hacer los dos pasos a mano, pero hay algunas diferencias sutiles que probablemente no te preocupen demasiado. (En particular, el fetchpaso ejecutado pulltrae solo origin/master y no actualiza la referencia en su repositorio: 1 cualquier confirmación nueva termina siendo referenciada solo por la FETCH_HEADreferencia especial).
Si usa la secuencia más explícita git fetch origin(luego, opcionalmente, mire a su alrededor) y luego git merge origin/master, también puede actualizar su propio local mastercon el control remoto, con solo una fetchejecución 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 cambiada (digo "reparada") en git 1.8.4, que ahora actualiza las referencias a "ramas remotas" de manera oportunista. (Fue, como dicen las notas de la versión, una decisión de diseño deliberada omitir la actualización, pero resulta que más personas prefieren que git la actualice. Si desea el antiguo SHA-1 de rama remota, de forma predeterminada se guarda en , y por lo tanto recuperable del reflog. Esto también habilita una nueva característica de git 1.9/2.0 para encontrar rebases ascendentes).
Al trabajar en mi sucursal local, me encanta mantenerme al día con las actualizaciones en la sucursal de desarrollo denominada dev.
Normalmente prefiero usar:
git fetch
git rebase origin/dev
Esto funcionó para obtener el código más reciente del maestro a mi rama:
git rebase origin/master
Si está en la rama de característica 1 y desea extraer master (tal vez para obtener las últimas actualizaciones fusionadas/reducir la posibilidad de conflictos de fusión), haga lo siguiente:
git pull
git merge origin/master
Atrae al maestro a su rama. ¡No afecta al maestro!
Esto atraerá todo lo que se haya convertido en maestro en su rama desde que ustedes dos divergieron.
Está bien hacer esto si su sucursal ya se ha hecho pública, ya que no reescribe el historial.
