tag - GitHub Merge rama ''maestro''

github api tags

Question

He estado probando Git y Github después de muchos años de uso. Parece que tengo lo básico, pero un elemento me confunde.

• UserA realiza un cambio en FileA y empuja al servidor remoto (GitHub)

• UserB hace un cambio a FileB. Primero extrae del servidor remoto y luego envía su cambio a FileB al servidor remoto

• El historial de confirmación de GitHub muestra el impulso de UserA y el impulso de UserB

• Sin embargo, hay una entrada adicional en el historial de confirmación de UserB llamada ''Merge branch'' master ''de https://github.com/xxx/yyy ''. Ver la diferencia en Github muestra que esta es una réplica exacta de los Cambios que el Usuario A realizó en el ArchivoA

¿Por qué se muestra este duplicado? Tanto la inserción de UserA a FileA como las entradas maestras de la rama Merge son idénticas ... la segunda me parece superflua.

Answer 1

Cada versión ("commit") almacenada en git forma parte de un gráfico, y con frecuencia es útil pensar en lo que estás haciendo en git en términos de ese gráfico.

Cuando comience UserA, digamos que solo se han creado dos confirmaciones, que llamaremos P y Q :

P--Q (master)

Luego modifica el archivo A, las etapas que cambian y crea un compromiso que representa el nuevo estado del código fuente; digamos que el compromiso se llama R Esto tiene un solo padre, que es el commit Q :

P--Q--R (master)

Después de empujar con éxito, el gráfico de confirmación para el repositorio de GitHub se ve igual.

UserB comenzó con el mismo historial:

P--Q (master)

... pero creó una confirmación diferente, llamada S , que tiene su versión modificada de FileB:

P--Q--S (master)

El usuarioB intenta enviar eso a GitHub, pero el rechazo se rechaza, a menos que "fuerce" el impulso, no se le permite actualizar una rama remota a menos que la versión que está presionando incluya todo el historial en esa rama remota. Entonces, UserB saca de GitHub. Un tirón realmente consiste en dos pasos, buscar y fusionar. La búsqueda recupera el origin/master , que es como un caché del estado del master rama remota desde el origin remoto. (Este es un ejemplo de una "rama de seguimiento remoto".)

P--Q--S (master)
    /
      R (origin/master)

La historia en este gráfico ha divergido, por lo que la fusión intenta unificar esas dos historias mediante la creación de un compromiso de fusión (digamos M ) que tiene a S y R como padres, y espero que represente los cambios de ambas ramas:

P--Q--S--M (master)
    /   /
     / /
      R (origin/master)

Cuando GitHub le muestra una diferencia que representa los cambios introducidos por la confirmación, es simple en el caso de una confirmación con un padre: solo puede hacer una diferencia con esa versión. Sin embargo, en el caso de un compromiso como M , con más de un padre, tiene que elegir un padre para mostrar la diferencia. Eso explica por qué la diferencia mostrada para la confirmación de fusión M parece ser la misma que la mostrada para S o R Las confirmaciones en git se definen por el estado exacto del árbol de origen, no por los cambios que llevaron al árbol a ese estado.