Il y a une phrase que je me suis dite en boucle pendant longtemps, à chaque fois que je m'apprêtais à faire un git push un peu plus gros que d'habitude : « et si ça mélange tout ? » Je n'avais jamais vraiment vérifié ce que ça voulait dire concrètement. Je tapais les commandes, ça marchait la plupart du temps, et je passais à autre chose sans creuser - avec, en fond, cette petite inquiétude jamais résolue.
Le problème n'est pas de ne pas comprendre - c'est de ne jamais vérifier
Ce n'est pas un manque d'intelligence. C'est un manque de vérification. Et la différence entre les deux, c'est tout l'objet de cet article.
Ce que fait vraiment un commit
Ce qui m'a débloqué, ce n'est pas une explication savante de Git. C'est une question toute simple que je me suis enfin posée : qu'est-ce qui se passe exactement si je supprime un fichier en local et que je pousse ensuite ?
Avant de chercher la réponse, j'imaginais un scénario flou où, quelque part, l'ancien fichier et le nouveau pourraient coexister bizarrement sur GitHub. Aucune preuve de ça - juste une inquiétude jamais mise à l'épreuve.
Voici ce que j'ai fini par comprendre, et qui a tout changé : Git ne fait pas qu'ajouter des choses. Un commit reflète l'état exact de ton dossier local au moment où tu le fais.
L'outil que je n'utilisais pas assez
Si je supprime un fichier chez moi, puis que je fais git add ., cette commande ne se contente pas de repérer les nouveaux fichiers et les fichiers modifiés - elle repère aussi les fichiers disparus. La suppression fait partie du commit, au même titre qu'un ajout. Résultat : quand je pousse, le dépôt GitHub finit par correspondre exactement à mon dossier local. Pas d'accumulation fantôme, pas de doublon caché quelque part. Si j'avais deux images dans un dossier et que j'en supprime une, GitHub se retrouve avec une seule image après le push - l'ancienne n'est plus dans l'arborescence actuelle, même si elle reste consultable dans l'historique si j'ai vraiment besoin d'y revenir un jour.
Les deux pièges qui restent réels
La vraie découverte, ce n'est pas une notion abstraite sur Git. C'est une commande toute bête que j'ignorais trop souvent : git status. Avant de faire add, commit et push, git status te dit noir sur blanc ce qui va se passer : quels fichiers seront ajoutés, lesquels seront modifiés, et surtout, lesquels seront supprimés.
Ce n'est pas une commande magique - c'est juste un miroir exact de ce que Git s'apprête à faire, avant de le faire. Une fois que j'ai pris l'habitude de la lancer systématiquement avant un commit un peu conséquent - surtout après avoir réorganisé des dossiers ou supprimé des fichiers -, l'inquiétude a disparu. Pas parce que j'avais enfin « compris Git » dans l'absolu, mais parce que je n'avais plus besoin de deviner : je pouvais voir.
Ce que je retiens
Si je déplace ou renomme un fichier plutôt que de simplement le supprimer, Git peut avoir du mal à détecter que c'est un renommage plutôt qu'une suppression suivie d'une création. Le résultat final reste correct, mais l'historique peut être moins lisible qu'on l'espérait. Et si un fichier est listé dans un .gitignore, sa suppression locale ne sera jamais proposée par git add ., puisque Git ne le suit pas du tout - s'il avait été ajouté au dépôt avant que le .gitignore n'existe, il faut le supprimer manuellement du dépôt pour qu'il disparaisse vraiment.