force - git rebase

diferencia entre git merge origin/master y git pull

Question

Estoy trabajando en una sucursal local "BDD-local" y me gustaría obtener los cambios de otros desarrolladores. Los otros desarrolladores están usando su propia rama y una vez que están contentos con las pruebas de unidad, empujan los cambios al repositorio remoto (origen / maestro).

Estaba revisando varias publicaciones aquí y obteniendo información contradictoria. Pocas personas hablan de usar:

git fetch origin
git merge origin/master

Algunos otros piensan, ''git pull'' debería obtener los cambios.

Uno de nuestros desarrolladores pidió usar ''git merge origin / master'' sin el ''git fetch''

¿Alguien sabe cuál de estas opciones es mejor? Intenté ''git pull'' en mi sucursal local pero no pareció funcionar. Pero si hago ''git pull'' en el maestro local, funciona bien (sin embargo, quiero que funcione para la sucursal local)

Answer 1

git pull es lo mismo que git fetch + git merge

El comando

git pull <remote> <branch>

es realmente lo mismo que

git fetch <remote>
git merge <remote>/<branch>

Así que no hay diferencia práctica entre

git pull origin master

y

git fetch origin
git merge origin/master

Documentación

Como se indica en la documentación oficial de Linux Kernel git pull :

En su modo predeterminado, git pull es una abreviatura de git fetch seguida de git merge FETCH_HEAD .

Más precisamente, git pull ejecuta git fetch con los parámetros dados y llama a git merge para combinar los cabezales de rama recuperados en la rama actual.

Lectura recomendada

• Pro Git § 2.5 Conceptos básicos sobre Git - Trabajar con controles remotos - Recuperar y extraer de sus controles remotos .

Answer 2

Un git pull va a ejecutar un git fetch y luego un git merge . Si desea actualizar su repositorio local con un repositorio remoto que es lo que ejecutaría.

Un git fetch importará confirmaciones de un repositorio remoto sin fusionarlas, lo que le brinda la oportunidad de revisarlas antes de integrarse.

Answer 3

buscar, fusionar y jalar

git fetch y git merge origin/master buscarán e integrarán cambios remotos. Déjame explicarte un escenario común. origen / maestro está en C. Alguien presionó D. Trabajó en E & F. Tenga en cuenta que no verá D en su repositorio local hasta que ejecute git fetch .

   origin/master
    v
A-B-C-E-F < master
     /
     (D) < master on remote

Ahora corres git fetch . Ahora puede ver D, y el origen / maestro se actualiza para que coincida con el repositorio remoto que está rastreando.

A-B-C-E-F < master
     /
      D < origin/master, master on remote

Ahora ejecutas git merge , dándote esto:

A-B-C-E-F
     /   /
      D---G < master
      ^
    origin/master, master on remote

Así que ahora ha integrado sus cambios en el maestro (E, F) con los nuevos confirmaciones en origen / maestro (D).

git pull es simplemente un atajo para los pasos anteriores.

git fusionar sin recuperar

Ejecutar git merge origin/master sin git fetch tiene sentido. Sin un git fetch , su repositorio local no tiene conocimiento de ningún cambio potencial en el repositorio remoto y el origen / maestro no se habrá movido. Así que estás en este estado, donde D está solo en el control remoto y no está presente localmente:

   origin/master
    v
A-B-C-E-F < master
     /
     (D) < master on remote

Dado que su repositorio local no tiene D, un git merge origin/master simplemente producirá:

Already up-to-date.

Porque hey, en lo que se refiere a su repositorio local, master ya tiene todo en origin / master.

Que es lo mejor

Ninguna de las anteriores. :)

git fetch
git rebase origin/master master

o un acceso directo, git pull -r , pero personalmente prefiero ver los cambios antes de volver a hacer una fase.
Esto volverá a reproducir sus cambios en el maestro (E, F) en la parte superior del origen / maestro (D) sin un cometer de fusión asquerosa. Cede:

A-B-C-D-E''-F'' < master
      ^
   origin/master, master on remote

Tenga en cuenta que todo está en una sola línea, está listo para empujar y la historia no parece un brazalete de amistad.

Una advertencia: nunca rebase ningún comentario que ya haya sido empujado. Tenga en cuenta que E & F se convirtió en E ''& F'' después de rebasar. Los compromisos son completamente reescritos, con un nuevo SHA y todo. Si vuelve a realizar las confirmaciones que ya son públicas, a los desarrolladores se les volverá a escribir su historial cuando tiren. Y eso es horrible, y todos te mirarán con maldad y te rechazarán.