remota - ¿Por qué Git fusiona una rama en sí misma?

git tag (4)

Me desperté esta mañana y miré el historial de confirmaciones de uno de los repositorios privados de mi equipo de desarrollo en BitBucket. Yo vi esto:

Anónimo cometido fcde879 MERGE
Merge branch ''develop'' de https://bitbucket.org/abc/xyz para desarrollar

Esto es, algo inusual. Mi suposición es que esto fue expulsado de una máquina nueva que no tenía GIT configurado correctamente. Aún así, no estaba seguro de por qué estaba haciendo esto. En BitBucket, muestra dos hashes separados como los padres de commit, pero no tiene la opción "view raw commit" de otros commits.

Revisé esa rama, tiré y miré el registro manualmente.

sidious@DS-1:/path/to/repo$ git log -1 --format=raw tree 2931d14f48e61eaf0bbe0660af5b5dd76c07f063 parent 6bb38dee681df7620ffa42b6790641a7873166f2 parent f59c82e19e3e79310a53e273bab78139c49ff063 author root <root@somemachine> 1437069530 +0000 committer root <root@somemachine> 1437069530 +0000 Merge branch ''develop'' of https://bitbucket.org/abc/xyz into develop

Por lo que puedo decir, el padre 6bb está en la rama de desarrollo y el padre f59 parece ser de una rama diferente. Es algo difícil de decir qué está pasando.

Busqué pero no pude encontrar una respuesta, y tengo que volver a la rutina, así planteo mi consulta aquí: ¿por qué git fusiona una rama en sí misma? O, más bien, ¿por qué se usa esta nomenclatura como el mensaje de compromiso?

El propietario tenía algunos commits en el desarrollo que no habían empujado, luego ejecutó git pull y fue a buscar / fusionarse en nuevos commits del desarrollo que estaban en el repositorio remoto.

He recibido el mismo tipo de mensaje. Merge branch ''feature/customfeature'' of https://mylocalrepo.com/project.git into develop y no ha roto nada aún jaja ... así que no Merge branch ''feature/customfeature'' of https://mylocalrepo.com/project.git into develop pánico. Solo está fusionando la rama de desarrollo remoto en su rama de desarrollo local. Mientras no surjan conflictos, deberías estar listo :)

Este escenario no es inusual.

La clave aquí es que las ramas fusionadas son diferentes: es la rama de develop del repositorio remoto fusionada en la rama de desarrollo local (de trabajo) del develop .

En el repositorio local del desarrollador hay dos ramas distintas:

develop = La rama en la que está trabajando actualmente. Los nuevos compromisos van aquí.
origin/develop = Esto es esencialmente una instantánea que guarda el repositorio actual sobre el estado de la rama de develop en el servidor remoto. Se actualiza con los cambios remotos cuando se fetch o se pull , y con los cambios locales después de un push exitoso.

Ahora, cuando lo haces, dos cosas pasan. Esto es porque git pull es esencialmente un alias para otras dos operaciones de git: fetch y merge :

fetch : trae todas las nuevas confirmaciones (si corresponde) del repositorio remoto a la rama de origin/develop local.
merge : toma los nuevos commits y los aplica a la develop branch trabajo local. Esto puede suceder de una de dos maneras:
- si la rama de trabajo local no contiene historial divergente (confirmaciones nuevas que el control remoto desconoce), simplemente avanza el puntero de develop bifurcación hacia delante, que apunta al último compromiso en origin/develop . Esto se conoce como una fusión de avance rápido .
- si el desarrollador tiene algunos commits nuevos que no están presentes en el repositorio remoto y, por lo tanto, no están en la rama de origin/develop , se realiza una fusión regular, lo que significa que hay un nuevo commit, que contiene los cambios de ambas ramas . De forma predeterminada, git asigna mensajes como estos a tales confirmaciones: Merge branch ''develop'' of https://bitbucket.org/abc/xyz into develop .

Entonces, el escenario es bastante común.

Ahora, si esto sucede muy a menudo y no te gusta ver gráficos de historial de compromisos muy complejos que contengan confirmaciones como la que estamos hablando, trata de utilizar rebase lugar de fusionar .

Puede hacer esto de dos maneras (al obtener los cambios del servidor remoto):

git fetch; git rebase
git pull --rebase

Si desea evitar este tipo de ocultación de fusión antes de tirar, de esta manera:

git stash git pull git stash pop