Luego de mucho batallar ya encontramos la contestación de esta problema que tantos usuarios de esta web han presentado. Si tienes algún detalle que aportar puedes dejar tu información.
Solución:
Estoy un poco confundido por los comandos que usas. HEAD Por lo general, es una etiqueta que usa git para rastrear la confirmación que se encuentra actualmente en el directorio de trabajo. los git fetch El comando espera un remoto o un compromiso remoto configuración para saber qué desea obtener. Utilizando git fetch HEAD indicaría HEAD es un control remoto en su repositorio. Que el comando funcionó sin errores es curioso.
Por ejemplo: git fetch HEAD en el repositorio en el que estoy trabajando actualmente da como resultado el siguiente error
fatal: 'HEAD' does not appear to be a git repository
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
El comando git remote enumerará todos los controles remotos, mientras que git remote --verbose incluirá la dirección del control remoto. ¿Podría usar esto para ver si tiene un control remoto definido como HEAD y que direcciones remotas del repositorio de tus amigos?
Sin embargo, mis preguntas a un lado y para ayudar a aclarar su confusión. los git fetch ... El comando solo actualiza las referencias remotas, no las locales.
Para aclarar esto, mire dentro de la carpeta .git en su repositorio (está oculta de manera predeterminada, por lo que es posible que deba mostrarla). Encontrará una estructura de carpetas similar a la siguiente
working directory
|=>.git
| |=>objects <= contains data for each commit
| |=>refs
| |=>heads
| |-master <= file containing current commit of local master branch
| |=>remotes
| |=>origin
| |-master <= file containing current commit of remote origin's master branch
|-FETCH_HEAD <= file updated by `git fetch`, contains info of what was fetched
Digamos que revisa la rama maestra, git checkout master - git cambiará su directorio de trabajo para que coincida con los datos de confirmación en la carpeta 'objetos' que coincida con el valor de confirmación en el archivo '.git / refs / heads / master'.
Si tu entonces git fetch origin master, el archivo '.git / refs / remotes / origin / master' se actualiza a la confirmación de la rama maestra en el origen remoto, y todos los datos de confirmación necesarios para esa confirmación se descargan y se colocan en la carpeta 'objetos'.
El punto importante aquí es git fetch no actualiza su directorio de trabajo refleja la sucursal local desprotegida y git fetch nunca actualiza una sucursal local.
Usando cualquiera git merge ... o git rebase ... es necesario para actualizar el local master rama con los cambios en origin/master. git pull ... hace ambos git fetch ... y también git merge ... o git rebase ..., dependiendo de las opciones y la configuración (git merge ... es el predeterminado).
Después de toda esa explicación, querrás poder ver qué, si es que algo, se obtuvo del repositorio de tus amigos. los git branch -avv El comando enumerará todas las sucursales locales y remotas, con los números de confirmación y, en el caso de las sucursales locales, qué sucursal remota está rastreando.
Para ver cómo las ramas se relacionan entre sí, encuentro útil usar una herramienta para graficar el árbol del repositorio. Hay varios para elegir, pero encuentro el git log comando suficiente; tal como git log --all --graph --oneline --decorate. Una advertencia justa, esto puede ser bastante largo y complicado para un repositorio grande. Se puede obtener una salida más corta agregando el --simplify-by-decoration argumento.
En resumen: si puedes arreglarlo en casa depende de la información de tu repositorio. Los comandos mencionados anteriormente; git remote --verbose, git branch -avv y git log ... debería darle una comprensión del estado actual de su repositorio. A partir de ahí, puede determinar si necesita hacer algo más para obtener los datos en sus sucursales locales usando git merge o git rebase.
Como siempre, si tiene problemas, publique lo que haya aprendido.
Desde git 1.8.4 (agosto de 2013), git fetch actualizará la rama de seguimiento remoto! No solo FETCH_HEAD.
Consulte la confirmación f269048 de Jeff King (peff):
Cuando ejecutamos un "
git fetch"sin argumentos, actualizamos las referencias de seguimiento de acuerdo con la especificación de referencia configurada.
Sin embargo, cuando corremos "git fetch origin master" (o "git pull origin master"), no examinamos las especificaciones de referencia configuradas y solo actualizamosFETCH_HEAD.Perdemos la oportunidad de actualizar "
refs/remotes/origin/master"(o lo que sea que haya configurado el usuario). Algunos usuarios encuentran esto confuso, porque querrían hacer más comparaciones con el estado anterior del maestro remoto, como:
$ git pull origin master
$ git log HEAD...origin/master
Pero eso supone que ha configurado su repositorio para buscar ramas:
git config remote.origin.fetch
Si esta vacio:
git config remote.origin.fetch '+refs/heads/*:refs/remotes/origin/*'
git fetch en realidad no toca su directorio de trabajo. Solo obtiene los últimos cambios de los controles remotos. Para actualizar realmente su estado actual, use git merge o git rebase. Además, puede utilizar git pull que funciona como atajo a git fetch + git merge.
La principal diferencia entre fusionar y rebase es que en algunos casos fusionar creará una nueva confirmación, con estado acumulado (fusión sin avance rápido). En mi humilde opinión, esto es malo, ya que me recuerda las veces que usé SVN. Rebase simplemente reproduce sus cambios en la parte superior de la confirmación especificada, por lo que su historial siempre es lineal. Solo asegúrese de utilizar el mismo flujo que sus colegas.
Te sugiero que leas algunas cosas sobre git en general y git flow: un libro de lectura obligada y un buen artículo.
Aquí tienes las comentarios y puntuaciones
Acuérdate de que puedes optar por la opción de añadir una estimación objetiva si te ayudó.