Repo 'repo' estado 'git' diciendo que la rama está por delante de origen/maestro. ¿Por qué?

Question

Así que aquí está la situación:

estado $ git
# En la rama principal
# Su rama está por delante de 'origin/master' por [x] se compromete.
#

Hay varias preguntas sobre esto en ya SO, pero ninguno parece abordar específicamente el tipo de escenario que tengo. This answer a una de las preguntas se acerca más, pero no entra en detalles.

sólo voy a citar textualmente:

Si recibe este mensaje después de hacer un "git pull sucursal remota", trate de seguir para arriba con un "git fetch".

Fetch parece actualizar la representación local de la rama remota, lo que no ocurre necesariamente cuando se hace una "rama remota de git pull".

Ese consejo sí funciona. Pero "¿no necesariamente sucede?" Por qué no? Necesito entender esto. ¿Qué es lo que no está haciendo?

no quiero que se encargue de esta cuestión, así que aquí está mi escenario en detalle:

tres equipos implicados. La Mac en la que desarrollo, mi servidor principal donde vive el repositorio git (es decir, el origen/principal) y una cuenta Webfaction que se extrae de ese servidor.

Realizo commits y git push origin master solo en la Mac. El único comando que se ejecuta en Webfaction como parte del flujo de trabajo normal es git pull origin master (como parte de un script de despliegue Fabric). No modifico el código allí. Soy un desarrollador solitario, por lo que tampoco lo hace nadie más.

De vez en cuando me conecto a Webfaction y verifico cosas, incluyendo un git status. Inevitablemente, siempre recibo el mensaje "Su sucursal está adelante ...". Ejecutando git fetch hace que el mensaje desaparezca.

Estoy a punto de agregar git fetch a la secuencia de comandos Fabric para hacer con este problema, pero quiero saber por qué es necesario hacerlo, especialmente en un clon pull-only de origen/master. No soy muy versado en Git, aunque utilizo la funcionalidad básica a diario, por lo que una explicación amigable para novatos sería apreciada.

actualización conforme a lo solicitado, los bits relevantes de config:

[remote "origin"] 
    fetch = +refs/heads/*:refs/remotes/origin/* 
    url = git@[server_address]:[path/to/repo.git] 
[branch "master"] 
    remote = origin 
    merge = refs/heads/master 

Answer 1

Ok, así que, desde el principio, está haciendo todo correctamente. Creo que el comentario que ha agregado anteriormente es una explicación bastante buena:

En los términos más simples, "git pull" no "buscar a git" un seguido de un "git merge"

Eso es como Lo pienso Así que no debería tener que llamar a git fetch después de un git pull directamente - pero, casi puedo garantizarle, esto funciona perfectamente bien en cualquier cosa, EXCEPTO la rama master.

En uno de los puestos vinculados, es decir para quitar la línea siguiente:

[remote "origin"] 
    fetch = +refs/heads/*:refs/remotes/origin/* <--- Remove this 

y debe solucionar este problema - sin embargo, no puedo dar una explicación de por qué esto funciona. Es muy difícil investigar, pero creo que cuando llamas al fetch, tu configuración de git realmente especifica exactamente qué agarrar. Cuando ejecuta pull, no estoy seguro de que piense que el master está sincronizado.

Te puedo garantizar que si lo hiciste desde otra sucursal no maestra, no verías este problema. Con suerte, uno de los gurús de git puede explicar la línea fetch en config en detalle.

Además, yo recomendaría que ejecuta el siguiente comando que establece la cabeza para el repositorio remoto para asegurarse de que está en sincronía con su local de uno: git push -u origin master

---

Aquí es otra cuestión interesante:

Having a hard time understanding git-fetch

---

Ok, así que probado esto en uno de mis flujos de trabajo y se encontró lo siguiente.

Cuando ejecuta un git pull origin master en su servidor remoto, hay un archivo en el directorio .git/ que hace referencia a dónde se encuentra su HEAD. Dos archivos a tomar nota de:

ORIG_HEAD

FETCH_HEAD

Se dará cuenta de que su FETCH_HEAD es correcta, pero el ORIG_HEAD muestra el antiguo confirmación, de ahí la razón de que está recibiendo la Ahead by x. Cuando ejecuta git fetch, en realidad corregirá la referencia en ORIG_HEAD y todo volverá a la normalidad. Estoy buscando cómo cambiar la línea fetch en la configuración para corregir este comportamiento.

Answer 2

Ver esta pregunta: What is the difference between 'git pull' and 'git fetch'?

yo sepa un git pull se verá en la sucursal en el origen y tire hacia abajo los cambios. Pero el índice local de la sucursal no está actualizado. git fetch actualizará el índice de la rama para que comprenda qué debería estar allí. (Básicamente, lo que se mencionó en la respuesta a la que vinculó)

Siempre hago una búsqueda de git antes de un jalón. Realmente hago una búsqueda de git cada vez que voy a hacer algo con sucursales remotas.

También se relaciona la pregunta anterior con esta muy buena descripción de git fetch, pull y merge. http://longair.net/blog/2009/04/16/git-fetch-and-merge/

Answer 3

Si ejecuta git pull origin en lugar de git pull origin master, no aparecerá el problema con el mensaje Your branch is ahead of 'origin/master' by ... commits..

Answer 4

En mi caso, tenía dos sucursales en Origin y cada vez que sacaba un git pull, mostraba que estaba delante del origen/master por x.Incluso después de restablecerlo en el origen/maestro como se muestra en Reset local repository branch to be just like remote repository HEAD.

La solución ocurrió cuando simplemente ejecuté git fetch y trajo mi rama de desarrollo a mi servidor de producción.