git pull del maestro a la rama de desarrollo

497

Tengo una rama llamada dmgr2 (desarrollo) y quiero extraer 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 confirmar los cambios:

git checkout dmgr2
git pull origin master

esto debería llevar los cambios en vivo a mi rama de desarrollo, ¿o me equivoco?

git branch pull

— Matthew Colley
fuente

1

primero confirme todos sus cambios en la rama dmgr2. y luego seleccione master 1.git checkout master y luego obtenga el último cambio 2.git pull 3.git merge dmgr2 4.git push -u origin master Y luego regrese a su dmgr2 5.git checkout dmgr2

— mat_vee

Ya he comprometido todos mis cambios a la rama dmgr2, lo siento, olvidé agregar eso

— Matthew Colley

1

si llevo a cabo el paso 4, ¿eso no empujará mis cambios de desarrollo a maestro? no quiero hacer eso

— Matthew Colley

Entonces, ¿lo que estás diciendo es que quieres llevar los cambios desde tu rama maestra a tu rama de desarrollo?

— JcKelley

99

Cambie a devrama con a git checkout dev. Entonces git pull --rebase origin master. Si tienes suerte, no habrá conflictos y el desarrollador tendrá los últimos cambios de master.

— jww

726

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 fetchcomando se puede hacer en cualquier momento antes del merge, es decir, puede intercambiar el orden de la búsqueda y el pago, porque fetchsimplemente va al control remoto nombrado ( origin) y le dice: "dame todo lo que tienes que no tengo ", es decir, todos los commits 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 se puede utilizar cualquier espectador ( git log, gitk, etc.) para ver "lo que tienen" que no lo hace, y viceversa. A veces esto solo es útil para Warm Fuzzy Feelings ("ah, sí, eso es de hecho lo que quiero") y otras veces es útil para cambiar estrategias por completo ("whoa, todavía no quiero ESO").

Finalmente, el mergecomando toma el commit dado, que puede nombrar como origin/master, y hace lo que sea necesario para incorporar ese commit y sus antepasados, a cualquier rama en la que se encuentre cuando ejecuta el merge. Puede insertar --no-ffo --ff-onlyevitar 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 indica a git que se ejecute git fetch, y luego el equivalente moral de git merge origin/master. Entonces, esto es casi lo mismo que hacer los dos pasos a mano, pero hay algunas diferencias sutiles que probablemente no le preocupan demasiado. (En particular, el fetchpaso ejecutado solopull trae , y no actualiza la referencia en su repositorio: ¹ cualquier nueva confirmación termina referida solo por la referencia especial ). origin/masterFETCH_HEAD

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 en 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.

¹ Esta segunda parte se ha cambiado, digo "arreglado", en git 1.8.4, que ahora actualiza las referencias de "rama remota" 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 personas prefieren que git lo actualice. Si desea que la antigua rama remota SHA-1, por defecto, se guarde en y, por lo tanto, recuperable del reflog. Esto también habilita una nueva característica git 1.9 / 2.0 para encontrar rebases ascendentes).

— torek
fuente

28

Solo estoy pidiendo un amigo, ¿cómo harías para deshacer el primer bloque de código que tienes aquí (pagar / buscar / fusionar)?

— Rich Bradshaw

10

@RichBradshaw: git checkoutnormalmente no es destructivo y normalmente no hay razón para deshacer un archivo git fetch, por lo que parece que estás preguntando cómo cancelar una confirmación de fusión. La respuesta es la misma que para otras confirmaciones: ya sea git reseto git revert. Para los cambios no publicadosgit reset suele ser el mejor método; para los cambios que otros ya tienen, git revertpuede ser mejor, pero vea los consejos de Linus Torvald para revertir una fusión: kernel.org/pub/software/scm/git/docs/howto/…

— torek

2

@WeDoTDD: no entiendo la pregunta. Hay una serie de comandos para ver el gráfico de comprometerse ( gitk, git log --graphcon o sin --oneline, etc.) y se puede git showo git show -muna combinación de cometer, o el uso git diff. En todos estos casos, está especificando el programa a medida que ingresa el comando en la línea de comandos.

— torek

1

@torek: intentó su forma de: git checkout branch y luego git pull origin master, pero extrajo todos los cambios maestros como un solo cambio que debe confirmarse localmente nuevamente, en lugar de extraerlos con su historial de confirmación y mensajes, así que después de actualizar local master y cambiando a branch, "git rebase master" hace el trabajo con todos los conflictos por resolver, y luego agrego a "git pull --rebase" y manejo nuevamente todos los conflictos, y luego git push origin branch para alinearnos todos. Supongo que debería haber una mejor manera de hacerlo, ¿estoy en lo cierto?

— user10556443

1

@torek: Estoy de acuerdo en que el resultado que obtuve es un proceso agotador que me obliga a manejar la repetición de rebase y fusión y ... cada vez que quiero obtener una actualización del maestro ... Pero, la forma propuesta, que admito es mucho más fácil, obtuve todos los cambios bajo un solo cambio no confirmado en la sucursal local sin mantener el orden / historial de confirmación maestro. Estaré encantado de conocer una mejor sugerencia sobre cómo usar "fetch" y realizar un seguimiento del master sin la necesidad de usar "pull", etc.

— user10556443

14

Situación : trabajando en mi sucursal local, pero me encanta mantener actualizaciones en la sucursal de desarrollo nombrada dev.

Solución : por lo general, prefiero hacer:

git fetch
git rebase origin/dev

— greenridinghood
fuente

15

Con el descargo de responsabilidad habitual de que el rebase solo debe hacerse si la rama local es solo local, es decir, no se ha empujado a ningún lado ya que reescribe el historial.

— Locus

8

Esto funcionó para mí. Para obtener el último código de maestro a mi sucursal

git rebase origin/master

— Pratik Gaurav
fuente

No te olvides de git fetch originprimero.

— lenooh

3

Escenario :

Tengo actualización maestra y actualización de mi sucursal, quiero que mi sucursal haga un seguimiento de la maestra con rebase, para mantener todo el historial rastreado correctamente, llamemos a mi sucursal Mybranch

Solución :

git checkout master    
git pull --rebase    
git checkout Mybranch    
git rebase master
git push -f origin Mybranch

necesita resolver todos los conflictos con git mergetool &, git rebase --continuar, git rebase --skip, git add -u, según la situación y las sugerencias de git, hasta que todo se resuelva

(corrección a la última etapa, por cortesía de Tzachi Cohen, usando "-f" obliga a git a "actualizar el historial" en el servidor)

ahora la rama debe estar alineada con el maestro y el rebase, también con la actualización remota, por lo que en el registro de git no hay "detrás" o "adelante", solo necesita eliminar todos los archivos de conflicto local * .orig para mantener la carpeta "limpia"

— usuario10556443
fuente