entendiendo git fetch luego fusionar

Viniendo de un background svn, tuve esta pregunta:

git equivalente al estado svn -u

(¿Cuál es el equivalente de git del svn status -u )

Y entiendo, tú lo haces:

 git fetch git log ..origin/master 

Pero, supongo que la parte de origin/master depende de la twig? ¿No sería necesariamente maestro si estuviera rastreando una sucursal remota?

Tampoco entiendo el git merge origin/master precisamente. Supongo que eso solo significa que git fetch tomó los cambios del control remoto y los puso en el sistema de database git como Origin / Master y estoy solo en master? ¿Qué ocurre si busco cambios, verifico lo que hice, estoy horrorizado por los cambios y no quiero fusionarme? ¿Cómo básicamente los abandono?

git fetch

git fetch capta los cambios del repository remoto y los coloca en la database de objects del repository. También recupera las sucursales del repository remoto y las almacena como sucursales de seguimiento remoto .

Cuando está buscando git le dice dónde almacena cada twig en el repository remoto que obtiene. Por ejemplo, debería ver algo así como

  7987baa..2086e7b master -> origin/master 

al ir a search Esto significa que las tiendas de 'origen / máster' donde 'maestro' está en el repository de 'origen'.

Si examina el file .git/config , verá el siguiente fragment:

 ["origen" remoto]
         url = git: //git.example.com/repo.git
         fetch = + refs / heads / *: refs / remotos / origen / *

Esto (entre otros) significa que cualquier twig 'A' ('refs / heads / A') en el origen remoto (repository del que clonaste) se saveía como 'origen / A' ('refs / remotes / origin / A') .

git log ..origin / master

Como puede ver, 'origin / master' es 'master' en origen. Si está en la twig 'master' (por defecto), entonces git log ..origin/master , que es equivalente a git log HEAD..origin/master , que cuando está en la twig 'master' es equivalente a git log master..origin/master enumeraría todas las confirmaciones que están en la twig 'principal' en el repository remoto y no están en la twig 'principal' local donde realiza su trabajo.

La versión más genérica en git moderno (suponiendo que exista información upstream / tracking) sería usar simplemente

 $ git log ..@{u} 

(Aquí @{u} es sinónimo de @{upstream} , consulte la página de manual de gitrevisions ).

git merge origen / master

git merge se usa para unir dos líneas de la historia. Si uno de los lados no hizo ningún trabajo desde el último punto de bifurcación (desde la base de fusión), la situación es rápida (la twig en la que se encuentra se actualiza simplemente a la punta de la twig que se está fusionando), o arriba hasta la date (no hay nada nuevo que fusionar, y la twig en la que se encuentra no se modifica).

git fetch seguido de git merge origin/master , cuando está en la twig 'master', es equivalente a issuing

 $ git pull 

Si no desea fusionarse, no es necesario. Tenga en count que puede usar, por ejemplo, git reset --hard HEAD@{1} para regresar y descartar el resultado de git pull si no le gusta.

git fetch descarga todos los cambios necesarios para representar la twig remota dada. Típicamente esto es origin/master o similar.

git merge fusiona dos twigs creando nuevos commits o fast-reenvíos (o una combinación). No cambia las confirmaciones que hayas realizado, y siempre puedes retroceder a tu antigua twig (usando git reset o git checkout ).

Tenga en count que git pull es git fetch seguido de git merge (o git rebase si se proporciona --rebase ).