Ignorar archivos y buenas prácticas
Clonas un proyecto llamado weather-app, ejecutas npm install, y verificas el estado de tu nuevo repositorio.
$ git status
Untracked files:
(use "git add <file>..." to include in what will be committed)
node_modules/
dist/
.envTres carpetas y archivos aparecen como sin rastrear, y ninguno de ellos pertenece a un commit. node_modules/ contiene miles de archivos que npm install regenera desde package.json en segundos. dist/ es la salida de compilación que se reconstruye desde tu fuente cada vez. Y .env contiene una clave API. Nada de eso debería llegar jamás al historial de tu proyecto, y escribir git add . sin pensar es cómo sucede de todas formas.
Indicarle a Git qué ignorar
Un archivo .gitignore lista patrones de archivos y carpetas que Git nunca debe rastrear. Lo creas una vez en la raíz de tu proyecto, en el mismo lugar donde ejecutaste git init cuando configuraste el repositorio en Tu primer repositorio, y desde entonces, git status y git add . omiten silenciosamente cualquier cosa que coincida.
# .gitignore
node_modules/
dist/
.envCada línea es un patrón: un nombre de carpeta simple como dist/ ignora esa carpeta completa, en cualquier lugar donde aparezca en el proyecto. Haz commit del archivo .gitignore en sí. Es pequeño, es útil para todos los que clonan el proyecto, y pertenece al historial de la misma manera que tu código fuente.
$ git status
On branch main
nothing to commit, working tree cleanCon los patrones en su lugar, git status se queda en silencio. Ese es exactamente el punto: las carpetas y archivos que nunca quieres hacer commit dejan de aparecer como ruido, así que las cosas que sí aparecen son las que realmente importan.
.gitignore lista lo que Git nunca debe rastrear: node_modules/, dist/, y .env son los sospechosos usuales en casi cualquier proyecto. Haz commit del archivo .gitignore en sí para que todos los que clonan el proyecto obtengan el mismo estado limpio. Desperdicié toda una tarde una vez organizando miles de archivos de dependencias por accidente antes de aprender esta. Nunca hagas commit de secretos
Una clave API, una contraseña de base de datos, o un certificado de firma nunca debe aparecer en un commit. Eso aplica para un repositorio privado tan firmemente como para uno público, y aplica desde el primer commit en adelante. Pon los secretos en un archivo como .env, agrega ese archivo a .gitignore el primer día, y carga los valores en tu aplicación desde allí en lugar de escribirlos en tus archivos de fuente.
# .env
WEATHER_API_KEY=sk_live_9f8e7d6c5b4a# .gitignore
.envSigue esta regla automáticamente, cada vez, sin excepciones. Una clave que está en un commit es accesible por cualquiera con acceso al repositorio, y en un repositorio público, por cualquiera en absoluto.
.env y agrega .env a tu .gitignore antes de ejecutar nunca git add. Esta es la única regla en este capítulo que vale la pena tratar como absoluta. Agregar un archivo a .gitignore después de que está rastreado
Este es el obstáculo que atrapa a casi todos al menos una vez. Haces commit de un archivo por accidente, te das cuenta de tu error, lo agregas a .gitignore (la línea echo de abajo añade la ruta a ese archivo), y esperas que Git lo olvide. No lo hace.
$ git add config/settings.json
$ git commit -m "Add app settings"
# más tarde, te das cuenta de que fue un error
$ echo "config/settings.json" >> .gitignore
$ git status
On branch main
nothing to commit, working tree cleangit status muestra un árbol limpio, pero config/settings.json todavía está rastreado y todavía aparece en cada git log futuro y en cada clon. Las reglas de ignore solo aplican a los archivos que Git aún no conoce. Una vez que un archivo ha sido agregado y hecho commit, es parte de tu historial, y .gitignore no tiene opinión sobre los archivos ya en ese historial.
Para dejar de rastrearlo realmente de ahora en adelante, dile a Git que suelte el archivo de lo que sigue mientras dejas el archivo en tu disco:
$ git rm --cached config/settings.json
$ git commit -m "Stop tracking config/settings.json"git rm --cached <file> elimina el archivo del rastreo de Git sin borrarlo de tu directorio de trabajo. Haz commit de esa eliminación, y desde ese punto en adelante tu patrón .gitignore hace el trabajo que querías que hiciera desde el principio.
.gitignore después de que Git ya lo rastrea no hace nada a ese archivo. Las reglas de ignore solo aplican a los archivos que Git nunca ha agregado. Para dejar de rastrear un archivo que se coló por accidente, ejecuta git rm --cached <file> y haz commit de ese cambio. Buenas prácticas: commits pequeños y un repositorio limpio
Un .gitignore ordenado es la mitad de mantener un repositorio que vale la pena trabajar. La otra mitad es cómo das forma a tus commits. Haz que cada commit sea un cambio enfocado: una corrección de error, una pequeña característica, un solo refactoring. Si una tarde de trabajo toca varias cosas no relacionadas, divídela en varios commits en lugar de dejarla caer todo en uno al final del día.
$ git add src/weather-widget.js
$ git commit -m "Fix temperature rounding in weather widget"Los commits pequeños son más fáciles de revisar, más fáciles de revertir si algo se rompe, y más fáciles de leer seis meses después cuando estás intentando recordar por qué una línea de código existe. El bucle de commit cubre lo que hace que un mensaje de commit sea útil; este hábito se trata de mantener el cambio en sí lo suficientemente pequeño para que un mensaje bueno sea incluso posible de escribir.
.gitignore cubriendo las carpetas y secretos que nunca deben ser rastreados. Esos dos hábitos juntos son la mayoría de lo que hace que un repositorio sea agradable de trabajar. Hábitos pequeños, formados temprano, te ahorran mucha limpieza después.