Une commande courte peut cacher plusieurs questions
Quand on apprend Git, il est tentant de mémoriser une suite de commandes et de la répéter jusqu’au prochain problème. Cette habitude fonctionne tant que la situation ressemble à l’exemple. Dès qu’un fichier inattendu apparaît ou qu’une branche diverge, il devient plus utile de comprendre l’état du travail que de chercher la prochaine commande à copier.
Je reviens donc souvent à git status. Sur quelle branche suis-je ? Quels fichiers ont changé ? Qu’est-ce qui est déjà préparé pour le prochain commit ? Ces questions paraissent élémentaires, mais elles ne disent pas la même chose. Les poser avant d’agir m’aide à choisir une commande en fonction d’une intention, au lieu d’espérer qu’elle corresponde au problème.
Le diff raconte le changement réel
Un nom de fichier ne suffit pas à décrire son contenu modifié. Lire le diff permet de voir les lignes ajoutées, retirées ou déplacées, et de les comparer au résultat recherché. Une ligne de débogage, une modification de configuration ou un changement de formatage peuvent s’y glisser sans faire partie de la tâche. Le dernier contrôle consiste à les reconnaître.
Dans un exemple fictif, corriger un libellé pourrait apparaître à côté d’une réorganisation entière du composant. La question n’est pas de refuser toute réorganisation, mais de comprendre pourquoi ces changements doivent être relus ensemble. Si leurs raisons sont différentes, les séparer peut rendre la relecture et une éventuelle correction plus faciles. La taille du diff devient alors une question de sens.
Préparer un commit qui a une raison d’exister
L’index permet de choisir ce qui entre dans le prochain commit. Je peux ainsi regarder le travail en cours et la version que je m’apprête à enregistrer comme deux états distincts. Cette séparation demande une vérification : ce qui fonctionne dans le dossier de travail doit correspondre au changement que le commit prétend contenir, surtout lorsque plusieurs tâches se croisent.
Le message vient ensuite. « Corriger le filtre des projets archivés » donne plus de contexte que « modifications », sans demander un long récit. Une explication supplémentaire peut être utile si le choix semble surprenant. Je veux surtout que l’historique permette de retrouver l’intention et de discuter du changement sans devoir reconstruire toute la séance de travail à partir des lignes.
Vérifier l’effet d’une commande avant de réparer
Reset, restore, checkout et rebase ne répondent pas aux mêmes besoins. Quand leur effet n’est pas clair, je préfère revenir à la question concrète : est-ce que je veux modifier un fichier, revoir ce qui est préparé ou changer l’histoire des commits ? Nommer cette intention réduit le risque d’utiliser une commande connue dans une situation où elle fait trop de choses.
La même prudence s’applique à un push forcé sur une branche partagée. Avant de remplacer un historique distant, il faut comprendre les différences et le contexte des autres personnes. Je n’en fais pas un raccourci pour faire disparaître un message gênant. Un dépôt partagé contient aussi le travail et les points de repère de l’équipe ; sa remise en ordre doit rester compréhensible.
Utiliser l’historique pour retrouver le raisonnement
Git me sert aussi à enquêter. Comparer deux versions ou relire un commit permet de demander quand un comportement a changé et avec quelle intention. L’historique apporte des indices, pas une explication automatique : il faut encore relier les lignes au fonctionnement de l’application. Des commits cohérents rendent cette recherche beaucoup moins confuse, même dans un projet personnel.
Les habitudes auxquelles je reviens sont donc assez modestes : regarder l’état, lire le changement, préparer ce qui a une raison commune et vérifier l’effet de la prochaine commande. Elles ne suppriment pas les erreurs. Elles rendent le travail plus explicable au moment où une erreur apparaît, ce qui est souvent le meilleur point de départ pour la corriger.