tag - fetch git, FETCH_HEAD y origen/master

git tag push

Question

Soy muy nuevo en git y tengo problemas con una simple operación de fetch .

Estoy tratando de obtener el progreso de un compañero de trabajo desde su repositorio. Al principio, logré git fetch HEAD que provocó que git descargara unos 350 MB de datos, así que estaba seguro de que había hecho algo. Sin embargo, el origin/master terminó apuntando al mismo antiguo commit (en realidad está bajo el nombre dev pero lo llamaré master , no tiene un master ).

Después de eso probé el git fetch origin master pero no pareció hacer nada, solo actualizó FETCH_HEAD . FETCH_HEAD confirmación FETCH_HEAD para no perderla, pero me gustaría tener una rama remota actualizada.

¿Qué fue lo que salió mal? No tengo acceso al repositorio remoto. ¿Puedo arreglarlo en casa?

Answer 1

git fetch realidad no toca tu directorio de trabajo. Solo busca los últimos cambios desde los controles remotos. Para actualizar realmente su estado actual use git merge o git rebase . Además, puedes usar git pull que funciona como atajo para git fetch + git merge .

La diferencia principal entre merge y rebase es que en algunos casos merge creará una nueva confirmación, con estado acumulado (fusión no rápida). En mi humilde opinión esto es malo, ya que me recuerda las veces que utilicé SVN. Rebase simplemente reproduce tus cambios en la parte superior de la confirmación especificada, por lo que tu historial siempre es lineal. Solo asegúrese de usar 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 .

Answer 2

Estoy un poco confundido por los comandos que usas. HEAD es generalmente una etiqueta que git usa para rastrear la confirmación que se encuentra actualmente en el directorio de trabajo. El comando git fetch espera una configuración de confirmación remota o remota para saber qué es lo que quiere obtener. El uso de git fetch HEAD indicaría que HEAD es un control remoto en su repositorio. Que el comando funcionó sin error es curioso.

Por ejemplo: git fetch HEAD en el repositorio en el que estoy trabajando 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 mostrará una lista de 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 qué direcciones remotas se refieren al repositorio de sus amigos?

Sin embargo, mis preguntas a un lado y para ayudar a aclarar su confusión. El comando git fetch ... solo actualiza las referencias remotas, no las locales.

Para que quede claro, busque dentro de la carpeta .git en su repositorio (está oculto de manera predeterminada, por lo que es posible que deba mostrarlo). 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

Supongamos que se registra en la rama principal, 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 luego 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 compromiso 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 rama local desprotegida y git fetch nunca actualiza una rama local.

Usando git merge ... o git rebase ... es necesario actualizar la rama master local con los cambios en el origin/master . git pull ... git rebase ... ambos git fetch ... y git merge ... o git rebase ... , dependiendo de las opciones y configuración ( git merge ... es el valor predeterminado).

Después de toda esa explicación, quieres poder ver qué, si acaso, fue extraído del repositorio de tus amigos. El comando git branch -avv todas las ramas locales y remotas, con números de confirmación y, en el caso de las sucursales locales, qué rama remota está rastreando.

Para ver cómo se relacionan las ramas entre sí, me resulta útil utilizar una herramienta para graficar el árbol del repositorio. Hay varios para elegir, pero creo que el comando de git log suficiente; como git log --all --graph --oneline --decorate . Advertencia razonable, esto puede ser bastante largo y complejo para un gran repositorio. Se puede obtener un resultado más corto agregando el --simplify-by-decoration .

Para resumir: si puedes arreglarlo en casa depende de la información en tu repositorio. Los comandos mencionados anteriormente; git remote --verbose , git branch -avv y git log ... deberían darle una git branch -avv del estado actual de su repositorio. Desde allí puede determinar si necesita hacer algo más para obtener los datos en su (s) rama (s) local (es) utilizando git merge o git rebase .

Como siempre, si tiene problemas, publique de vuelta con lo que aprende.

Answer 3

Lo que quieres hacer es:

• Agregue un control remoto para su compañero de trabajo
• Obtener los cambios de su repositorio
• Crea una rama local que se refiera a su rama remota

Presumiblemente, ya has hecho el paso # 1. Pero para completar, es:

git remote add coworker git://path/to/coworkers/repo.git

donde la URL puede ser cualquier formato de URL que admita git.

Ahora que tiene el control remoto agregado, quiere recuperar sus cambios:

git fetch coworker

Esto te da ramas remotas para cada una de sus ramas. Digamos que su rama se llama "hámster". Ahora, para hacer el trabajo, usted crea su propia copia local de la rama remota

git checkout -b hamster coworker/hamster

Esto crea y te cambia a una rama llamada hámster.

A partir de ese punto, puedes trabajar en hámster y empujarlo hacia él con

git push coworker hamster

la primera vez, y luego simplemente git push después de eso.

Cada vez que desee desplegar y fusionar sus cambios, puede hacer:

git pull

Answer 4

Desde git 1.8.4 (agosto de 2013), git fetch actualizará la rama de seguimiento remoto. No solo FETCH_HEAD .

Ver commit f269048 de Jeff King ( peff ) :

Cuando ejecutamos una "recuperación de git" regular sin argumentos, actualizamos las referencias de seguimiento de acuerdo con el refspec configurado.
Sin embargo, cuando ejecutamos " git fetch origin master " (o " git pull origin master "), no miramos las refspecs configuradas, y simplemente actualizamos FETCH_HEAD .

Perdimos la oportunidad de actualizar " refs/remotes/origin/master " (o lo que el usuario haya configurado). Algunos usuarios encuentran esto confuso, porque querrían hacer más comparaciones con el viejo estado del maestro remoto, como:

$ git pull origin master
$ git log HEAD...origin/master