git muy a fuego lento y eso implica que, en vez de ver solamente acción de buenas a primeras, necesitamos tener cierta base clara.Voy a explicar algo que parece demasiado obvio pero que luego veo que mucha gente no caemos en ello a nivel práctico.
Ficheros nuevos
Cuando hablamos de un fichero nuevo significa que no lo tenemos en el repositorio de git es decir, no lo tenemos en un commit.
Por ejemplo si ahora creamos un fichero por ejemplo primerFicheroNuevo.txt y hacemos un git diff no nos devolverá nada y pensarás, "es que no tiene nada que enseñar porque ese fichero está vacío". Bueno, realmente si que podría tenerlo en cuenta pero de momento no se lo estamos diciendo...
Creamos otro fichero segundoFicheroNuevo.txt y escribimos dentro la frase "cualquier cosa". Ahora si hacemos git diff.
¿Nos debería de mostrar lo que había antes y lo que hay ahora? Venga prueba... vaya pues da igual que el fichero este vacío como primerFicheroNuevo.txt como le añades contenido como segundoFicheroNuevo.txt no se muestra nada.
¿Qué está pasando?
Lo que pasa es que como el nuevo archivo no es rastreado por git cuando lo creas (está en el workspace recuerda), este no tiene manera de identificar lo que ha cambiado porque no está en el repositorio local.
$ git add segundoFicheroNuevo.txt Ahora ya tenemos en el staging area solamente ese fichero (si no comprueba con git status) pero todavía no podemos hacer git diff, tendremos que hacer un commit para que sepa que está en el repositorio:
git commit -m "Añadido segundo fichero"git log que tenemos el commit creado.Ficheros susceptibles de actualizar
Ahora sí nuestro segundoficheroNuevo.txt es un fichero que, si queremos seguir trabajando en él, git ya lo conoce y por lo tanto es un fichero susceptible de ser actualizado.
Vamos editar el fichero y a añadir el párrafo "otra cosa" debajo de lo que habíamos escrito. Ahora si podemos hacer git diff segundoFicheroNuevo.txt y nos devolverá lo siguiente:
new file mode 100644
index 0000000..e69de29
diff --git a/segundoFicheroNuevo.txt b/segundoFicheroNuevo.txt
index 4b39b64..a96acad 100644
--- a/segundoFicheroNuevo.txt
+++ b/segundoFicheroNuevo.txt
@@ -1 +1,2 @@
Cualquier cosa
+otra cosaEn verde tenemos lo que está añadido.
Hagamos magia
¿Recuerdas que hemos dejado un primerFicheroNuevo.txt en el workspace y sin añadir, verdad? Comprueba si quieres con git status que está en rojo y sin trackear. Recuerda que no podíamos hacer git diff porque en teoría no tenemos ningún cambio y aunque añadamos cosas tampoco nos saldría nada. Pues vamos a cambiar eso!
$ git add -N primerFicheroNuevo.txtAhora haz un git diff... oh vaya, MAGIA
diff --git a/primerFicheroNuevo.txt b/primerFicheroNuevo.txt
new file mode 100644
index 0000000..e69de29
Y dime una cosa, ¿Ese fichero está en staging area? Compruébalo con git status:
En la rama main
Cambios no rastreados para el commit:
(usa "git add <archivo>..." para actualizar lo que será confirmado)
(usa "git restore <archivo>..." para descartar los cambios en el directorio de trabajo)
nuevo archivo: primerFicheroNuevo.txt¡Vaya! ¡En rojo! Es como si siguiera en el workspace pero podemos tratarlo como si fuera... un fichero a actualizar, o más bien un fichero que estuviera en el repositorio local.
Ahora algo también interesante, borra ese fichero con rm segundoficheroNuevo.txt y vuelve a crearlo con el mismo nombre, ¿Se creará un fichero nuevo o lo trata como un fichero a actualizar? Pues entiende que es el mismo fichero a actualizar porque git no tiene trackeado el borrado (como consecuencia puedes hacer el git diff otra vez xD).
Conclusión
Con el comando git add -N <nombre del fichero> podemos hacer que git entienda los ficheros nuevos como ficheros que ya existen pero sin pasar al staging area.
git add como un proceso de pase del workspace al staging area para tener trackeados los ficheros pero en este caso se queda en el workspace por la justificación que os he explicado antes.Este aprendizaje es necesario para lo que vendrá más adelante pero ya es cosa de otro día.
Comentarios