Ton premier dépôt : init, add, commit

Dans les trois premières leçons, on a construit l'image dans notre tête : pourquoi le contrôle de version existe, et comment Git pense ton projet. Maintenant, on touche l'outil pour la première fois et on crée une vraie sauvegarde. Ce qui embrouille le plus les gens au début, c'est que Git ne « sauv

Imagine le staging comme le fait d'emballer une boîte avant de la sceller et de l'expédier : git add choisit ce qui entre dans la boîte, et git commit la scelle et l'inscrit dans l'historique pour toujours.

Arbre de travail: Le dossier où vivent tes fichiers et que tu modifies. Un changement ici n'est pas encore sauvegardé dans Git tant que tu ne l'as pas ajouté (add) et commit.
Zone de staging: Un arrêt intermédiaire où tu emballes exactement les changements qui iront dans la prochaine sauvegarde. git add place un changement ici, comme on met un objet dans la boîte.
git init: Démarre le suivi de versions dans le dossier actuel. Il crée un sous-dossier caché nommé .git qui contiendra tout l'historique.
git add: Déplace les changements de l'arbre de travail vers le staging — autrement dit, choisit ce qui ira dans la prochaine sauvegarde.
git commit: Scelle tout ce qui est en staging en une sauvegarde permanente (un commit) dans l'historique, avec un court message expliquant le changement.