El estado de git no muestra files modificados

Creé una twig, di 'new_branch' desde la twig de desarrollo en bitbucket y desde mi local cambio a ella

git checkout -b new_branch 

Después de que git tire del código, lo intenté

 git status 

para ver los files modificados.

Sin embargo, desde el resultado, no vi un file que sabía que se había modificado, otros files modificados parecían correctos.

Para ese file en particular, diga 'test.cs', lo hice

 git diff origin/new_branch -- local-path/test.cs 

y confirmar el cambio, pero ¿cómo es que no se mostró en la salida de "estado de git"?

Como resultado, no puedo agregar / confirmar / insert el file.

¿Alguien puede ayudar? Espero haber sido claro.

No está claro para mí lo que piensas que está mal.

Observemos aquí que el git status informa muchas cosas. La información sobre files específicos, como local-path/test.cs , proviene de dos commands git diff , pero no del que está ejecutando.

El índice / área de ensayo

En un repository de Git normal, hay tres elementos de interés con respecto a cada file. Existe el estado del file en su confirmación actual (o HEAD ). Existe el estado del file en su tree de trabajo, donde puede editar el file con sus editores favoritos, ejecutar cualquier command normal en él, y así sucesivamente. Y, está el estado del file en el índice de Git, también llamado "área de ensayo" de Git.

El área de preparación es, en esencia, "lo que entrará en el próximo compromiso que hagas". Recuerde que en Git, cada confirmación es una instantánea completa de su trabajo: cada file que se organiza (o "seguimiento", es decir, no es un "file sin seguimiento") se registra exactamente como aparece en el área de transición. Una vez que realice la confirmación, el área de preparación coincide con la confirmación que acaba de realizar. No está vacío, está lleno de files, pero una git diff que compara la confirmación con el índice estará vacía, porque el índice y la confirmación contienen el mismo tree de trabajo almacenado. Si luego modifica un file en el tree de trabajo y lo git add , Git reemplaza la versión del índice con la versión del tree de trabajo, de modo que ahora el índice y el compromiso HEAD difieren.

git status y git diff

Con eso en mente, echemos un vistazo a su command específico de git diff , y la documentation de git diff . Tu corres:

 git diff origin/new_branch -- local-path/test.cs 

La documentation dice, en parte:

git diff [--options] <commit> [--] [<path>...]
Este formulario es para ver los cambios que tiene en su tree de trabajo en relación con el <commit> nombrado. Puede usar HEAD para compararlo con la confirmación más reciente o un nombre de twig para comparar con la punta de una twig diferente.

Esto significa que estaba comparando la versión del tree de trabajo de local-path/test.cs con la versión en el commit en la punta de origin/new_branch .

La versión de índice del file no tiene parte en esta comparación.

Ahora veamos qué diferencias de git status . Estas citas siguen siendo de la documentation de git diff :

git diff [--options] --cached [<commit>] [--] [<path>...]
Este formulario es para ver los cambios que realizó para la siguiente confirmación relacionada con el <commit> nombrado. Por lo general, desearía comparar con la última confirmación, por lo que si no le da <commit>, se convierte en HEAD. Si HEAD no existe (por ejemplo, twigs no nacidas) y <commit> no se da, muestra todos los cambios por etapas. –staged es un sinónimo de –cached.

Puede pasar por alto la extraña noción de "twig no nacida" aquí. Esto compara un compromiso específico versus el índice. Por defecto, compara HEAD vs el índice. Esto te dice qué sería diferente en un nuevo compromiso.

Esta es la primera diferencia que hace el git status , para saber qué cometerías si cometieras ahora.

También encontramos, en la documentation de git diff , esto:

git diff [--options] [--] [<path>...]
Este formulario es para ver los cambios que hizo en relación con el índice (área de ensayo para el siguiente compromiso). En otras palabras, las diferencias son lo que podrías decirle a Git que agregue aún más al índice, pero aún no lo has hecho. Puedes organizar estos cambios usando git-add (1).

En otras palabras, esto compara el índice con el tree de trabajo. Lo que se muestre como diferente aquí, puede git add a su índice, de modo que se muestre en la primera diferencia que se ejecuta el git status . En cambio, actualmente aparece en la segunda diferencia que se ejecuta el git status .

Después de que el git status haya ejecutado estos dos diffs, imprime todos los files que aparecieron en uno, como "cambios orderados para confirmación" o "cambios no procesados ​​para confirmación", o, en algunos casos, ambos . (Por ejemplo, puede agregar una línea a README y README etapa, luego agregar otra línea a README pero no ponerla en etapa todavía. Ahora tiene cambios de HEAD a índice -la primera línea que agregó- y cambia de index a work-tree : la segunda línea que agregaste)

De nuevo, el git status informa todo esto. Usted dice que no informa nada: esto significa que su confirmación HEAD coincide con su índice, y su índice coincide con su tree de trabajo. Hay un caso especial a considerar antes de seguir adelante.

Para los files sin seguimiento, que por definición no están en el índice y no están en el git status compromiso HEAD normalmente los informa como "files sin seguimiento". Esto a menudo es más molesto que útil, por lo que puede usar .gitignore para indicarle al git status que se calle acerca de estos files. Compruebe su .gitignore para ver si está ignorando local-path/test.cs Presumiblemente no lo es, pero si lo es, esa podría ser la razón por la que no verías nada.

Poniendolo todo junto

También dices que si git diff origin/new_branch -- local-path/test.cs , ves diferencias. Esto significa que su tree de trabajo no coincide con el compromiso al que apunta el origin/new_branch .

Desde el git status (y suponiendo que no .gitignore acción de .gitignore ), sabemos que las versiones HEAD y work-tree de local-path/test.cs son las mismas. Y, vemos que la versión de origin/new_branch de local-path/test.cs es diferente. Por lo tanto, podemos concluir que la versión HEAD no es la versión origin/new_branch : deben ser dos commits diferentes.

Este es un estado perfectamente normal. Sin embargo, a veces el git status informa algo más para este estado.

Ramas stream arriba

Específicamente, cada twig puede tener una twig ascendente . No se requiere ninguna twig para tener una twig ascendente, y no existe ninguna restricción en la forma de la twig ascendente, si hay una, pero cada twig puede tener una, y solo una, en sentido ascendente.

Normalmente, una twig local como master o new_branch general tiene una twig de seguimiento remoto como origin/master u origin/new_branch como su ascendente.

La existencia del upstream es, nuevamente, opcional. Pero si hay uno, el git status usa para comparar la twig actual contra la anterior.

Específicamente, si new_branch tiene origin/new_branch establecido como upstream, y si -como creemos que acabamos de probar- new_branch y origin/new_branch difieren, el git status nos dirá que una twig está delante de la otra, o detrás de la otra, o ambos. (El command git status hace esto comparando los commits -no sus contenidos, solo los commits mismos- a los que se puede acceder desde las dos twigs. No entraré en más detalles aquí, para get más información al respecto, consulte esta respuesta . )

Nada de esto puede ocurrir a less que la twig actual tenga un set ascendente.

Usted escribió que corrió:

 git checkout -b new_branch 

Esta forma de git checkout de git checkout crea una nueva twig y, de forma pnetworkingeterminada, no establece un flujo ascendente para ella .

Para establecer un git branch --set-upstream-to ascendente, use la git branch --set-upstream-to (consulte la documentation de la git branch para get más información).

Tenga en count que el git checkout name , cuando el name no existe actualmente como una twig local, pero existe el origin/ name , creará el name sucursal local con su set ascendente en origin/ name . Esto es muy diferente de git checkout -b , que crea una sucursal local sin un set ascendente (y a menudo un valor de inicio diferente para la sugerencia de bifurcación).