Estoy tratando de enviar mis archivos a github usando bash. Ya están allí, y estoy subiendo una versión más nueva con nuevas líneas y código, etc. Pero cuando lo intento git addy luego git statusdice:
En el maestro de la sucursal
nada que confirmar, directorio de trabajo limpio
Y el archivo que estoy usando se acaba de modificar.
git diff(o git status) no muestra nada que explique por qué no hay nada que agregar. Entonces, la pregunta es: "¿Por qué git no reconoce que mi archivo ha sido cambiado?"
Respuestas:
Tuve un problema en el que una vez configuré el índice de git para 'asumir sin cambios' en mi archivo.
Puedes decirle a git que deje de ignorar los cambios en el archivo con:
git update-index --no-assume-unchanged path/to/file
Si eso no ayuda, un reinicio puede ser suficiente para otros casos extraños.
En la práctica, encontré eliminar el archivo en caché y restablecerlo para que funcione:
git rm --cached path/to/file
git reset path/to/file
El git rm --cachedmedio para eliminar solo el archivo del índice y resetle dice a git que vuelva a cargar el índice de git desde la última confirmación.
git add -f path/to/the/fileagregará a la fuerza los archivos para confirmar.
git add -fel archivo que estaba en este estado de "asumir sin cambios", y no funcionó - tenía que hacerlo git update-indexo git rm --cachedseguido de un git resetpara que funcionara.
git rm --cached -r .y luego git reset ..
git update-index --no-skip-worktree path/to/fileasí es como resolví mi problema
Revise su .gitignorearchivo . Puede encontrar que el archivo, o la extensión del archivo, o la ruta al archivo con el que está tratando de trabajar coinciden con una entrada .gitignore, lo que explicaría por qué ese archivo se ignora (y no se reconoce como un archivo modificado).
Este resultó ser mi caso cuando tuve un problema similar.
lib/, lo que hace que git ignore esta carpeta. No hay ningún problema con eso, al menos si esta carpeta no es la carpeta principal de su proyecto, como lo que me pasó a mí.
Como ya se discutió, los archivos probablemente fueron marcados con "asumir sin cambios", lo que básicamente le dice a git que no modificará los archivos, por lo que no necesita hacer un seguimiento de los cambios con ellos. Sin embargo, esto puede estar afectando a varios archivos y, si se trata de un espacio de trabajo grande, es posible que no desee comprobarlos todos uno por uno. En ese caso, puede probar: git update-index --really-refresh
de acuerdo con los documentos:
Like --refresh, but checks stat information unconditionally, without regard to the "assume unchanged" setting.
Básicamente, obligará a git a realizar un seguimiento de los cambios de todos los archivos, independientemente de los indicadores "asumir sin cambios".
git statusdice que no se cambian los archivos, pero git add .agrega dos archivos, y git update-index --really-refreshdice que esos dos necesitan actualizaciones, pero no parece hacer nada. ¿Alguna idea?
git ls-files -v | grep '^[[:lower:]]'Si nada ayuda, debe crear una pregunta con más detalles para que podamos ayudar tú.
Suena loco, pero a veces no estás en el repositorio correcto aunque creas que lo estás. Por ejemplo, es posible que haya movido el directorio principal, pero olvidó cambiar de repositorio en su editor de texto. O viceversa: estás en el repositorio correcto en el editor de texto pero en el repositorio incorrecto en la línea de comandos. En la primera situación, realiza sus ediciones en el archivo correcto , pero no es la misma carpeta que está abierta en su línea de comando, por lo que en realidad es el archivo incorrecto. En la segunda situación, en realidad editó el archivo correcto, pero su línea de comando git no reconocerá el cambio porque no está en el directorio correcto en la línea de comando.
bueno, no tenemos suficiente para responder a esta pregunta, así que te daré varias conjeturas:
1) guardó sus cambios, para corregir el tipo: git stash pop
2) tuvo cambios y los cometió, debería poder ver su compromiso en git log
3) git reset --hardTuviste cambios hechos de alguna manera , tus cambios pueden estar allí en el reflog, escribe git reflog --allseguido de verificar o seleccionar la referencia si alguna vez la encuentras.
4) ha revisado el mismo repositorio varias veces y está en el incorrecto.
git commit --amendpuede poner sus nuevos cambios en su última confirmación , no hagas eso si ya has compartido tu compromiso.
Ha pasado algo raro como esto. El complemento git de Eclipse Kepler marcaba automáticamente todas las carpetas de mi proyecto como ignoradas en la carpeta .gitignore.
Cuando me llegó a commiten el Teammenú, todos ellos se vuelve a establecer en ignorado. Por lo que puedo decir, esto se debió a que los configuré como derivados en el proyecto principal. Desmarcarlos como derviedsolucionó esto. Nunca había visto esto antes en Indigo. Espero que ayude a alguien.
TL; DR; ¿Estás siquiera en el repositorio correcto?
Mi historia es un poco divertida, pero pensé que podría suceder con alguien que podría estar pasando por una situación similar, así que la comparto aquí.
En realidad, en mi máquina, tenía dos repositorios git separados repo1y los repo2configuré en el mismo directorio raíz llamado source. Estos dos repositorios son esencialmente los repositorios de dos productos con los que trabajo intermitentemente en mi empresa. Ahora bien, la cuestión es que, como pauta estándar, la estructura de directorios del código fuente de todos los productos es exactamente la misma en mi empresa.
Entonces, sin darme cuenta, modifiqué exactamente un archivo con el mismo nombre en el repo2que se suponía que debía cambiar repo1. Por lo tanto, no dejé de sistema que se ejecuta git statusen repo1Y siguió dando el mismo mensaje
En el maestro de la sucursal
nada que confirmar, directorio de trabajo limpio
durante media hora. Luego, un colega mío lo observó como un par de ojos independientes y me hizo notar que estaba en un repositorio equivocado pero de aspecto muy similar. En el momento en que repo1cambié a Git, comencé a notar los archivos modificados.
Caso no tan común. ¡Pero nunca se sabe!
Esto sucedió en Windows al cambiar archivos al transferir diferencias a través de la herramienta WinMerge. Aparentemente, WinMerge (al menos la forma en que está configurado en mi computadora) a veces no actualiza las marcas de tiempo de los archivos que cambia.
En Windows, git status usa, entre otras cosas, la marca de tiempo de un archivo y cambios en el tamaño del archivo para determinar si un archivo ha cambiado o no. Entonces, dado que la marca de tiempo no se actualizó, solo tenía el tamaño del archivo para pasar. Desafortunadamente, el archivo en cuestión era un archivo de versión simple donde el contenido cambió de 7.1.2 a 7.2.0 . En otras palabras, el tamaño del archivo tampoco se modificó. Otros archivos que también fueron cambiados por WinMerge y no tenían sus marcas de tiempo actualizadas pero tenían un tamaño diferente después de que el cambio fue detectado por git status sin problemas .
Tuve un problema similar mientras usaba Sublime Text-3 . Después de hacer nuevos cambios en el código y guardarlo, cuando probé los comandos git add ./status, la respuesta fue "rama ya actualizada". Me di cuenta de que, independientemente de guardar las actualizaciones en el editor de texto, el archivo no había cambiado. Abrir el archivo en otro editor y guardar los cambios funcionó para mí.
¿Sacaste el directorio de debajo de tu shell? Esto puede suceder si restauró su proyecto desde una copia de seguridad. Para solucionar este problema, solo cdsalga y vuelva a entrar:
cd ../
cd -
En general, con este problema, primero verifique que está editando el archivo que cree que está. Tuve este problema cuando estaba editando un archivo JavaScript transpilado en lugar del archivo fuente (la versión transpilada no estaba bajo el control de la fuente).
Mi cliente de Git (Gitg) me causó este problema. Los comandos normales que normalmente ejecutaría no funcionaban. Incluso tocar todos los archivos del proyecto no funcionó.
Encontré una manera de solucionarlo y todavía no estoy seguro de qué lo causó. Copie el directorio de su proyecto. Los archivos faltantes aparecerán en el directorio copiado git status. Cambiar el nombre podría hacer lo mismo.
Me encontré con el problema, pero eran solo dos directorios y no sabía que ambos directorios terminaron configurados como submódulos git. No tengo ni idea de cómo sucedió eso, pero el proceso fue seguir algunas de las instrucciones de este enlace, pero NO eliminar el directorio (como lo hace al final), sinogit add path/to/dir
Cuando edita un archivo en Visual Studio, aparece en la lista de cambios de git instantáneamente, incluso si el archivo no se guarda. Entonces, todo lo que necesita hacer es guardar el archivo manualmente (Ctrl + S para el archivo que se muestra actualmente o Ctrl + Shift + S para todos los archivos del proyecto) y git bash los recogerá.
.jsarchivo, trabajando con Visual Studio Code. Gracias.
Asegúrese de no crear enlaces simbólicos ( ln -s source dest) desde dentro de Git Bash para Windows.
NO hace enlaces simbólicos, pero hace una copia PROFUNDA de la fuente al destino
Experimenté el mismo comportamiento que OP en una terminal MINGW64 de Git Bash para Windows (versión 2.16.2) para darme cuenta de que mis cambios 'editados' en realidad estaban en el directorio original, y mis comandos git bash provenían de una copia profunda que había quedado sin alterar.
A mí también me pasó, probé los métodos mencionados anteriormente y nada ayudó. Entonces, la solución fue cambiar el archivo a través de la terminal, no la GUI. No sé por qué esto funcionó, pero funcionó. Después de editar el archivo a través de nano desde la terminal, git lo reconoció como cambiado y pude agregarlo y confirmarlo.
Tengo el mismo problema aquí VS2015 no reconoció los cambios de mis archivos js, eliminando los controles remotos de la configuración del repositorio y luego volviendo a agregar la ruta URL remota resolvió mi problema.
En mi caso, hacer un git reset --hardarchivo eliminado y dejar algunas carpetas vacías. Después de inspeccionar el contenido, noté que los directorios estaban vacíos.
Sin embargo, git ignora las carpetas vacías. (Corrección, git ignora todos los directorios ya que rastrea el contenido, las carpetas vacías no son contenido).
intenta usar git add *
entoncesgit commit