Solución:
Verifique si localmente tiene una subcarpeta .git / debajo de esa carpeta.
Eso significaría que la carpeta (localmente) es una repositorio de Git anidado, cuyo árbol SHA1 está registrado como “gitlink” (carpeta gris con flecha blanca recta)
Lo que verías en GitHub es ese gitlink: el nombre del objeto de la confirmación en la que el superproyecto espera que esté el directorio de trabajo del repositorio (o submódulo) de Git anidado.
Si ves un folder @ xxx
, entonces es una entrada de submódulo, lo que significa que su propio repositorio tiene una .gitmodules
en él, que registra, además del gitlink, la URL real del repositorio remoto.
A git clone --recurse-submodules
restauraría el contenido de ese submódulo (a diferencia de un repositorio de Git anidado, donde su URL es no grabado, y el contenido de la carpeta permanecería vacío)
La flecha puede significar que es un submódulo.
Tu podrías intentar:
git add yourfolder
Si eso da como resultado un error como:
xxx submodule xxx
aparece, puede intentar esto:
git rm --cached gitbook
Entonces, podría ejecutar con éxito:
git add yourfolder
En su máquina, si navegó al directorio con la flecha e intentó ver los archivos ocultos, verá un .git
carpeta, indicando que es un repositorio. Esto significa que es un repositorio contenido dentro del repositorio externo que ha enviado a GitHub. La forma más fácil de deshacerse de la flecha y comenzar a ver sus archivos correctamente (en mi opinión) es eliminando el .git
carpeta. De esa manera, deja de convertirse en un repositorio de git y vuelve a ser una carpeta normal. Ahora, cuando empuja a GitHub, normalmente puede acceder a la carpeta y ver todo su contenido.