Introduction

La plupart des gens apprennent Git à la dure, à travers de petits désastres. Cette page rassemble les erreurs de débutant les plus fréquentes et comment les éviter (ou s'en remettre). Lisez-la une fois maintenant et de nouveau après un mois d'utilisation ; la deuxième lecture aura plus de sens.

Commiter avec la mauvaise identité

Oublier de définir user.email par dépôt expose des adresses personnelles dans les commits professionnels. Définissez toujours une identité par dépôt dans les clones de travail :

git config user.email "[email protected]"
git log -1 --pretty=format:"%an <%ae>"

Commiter des secrets

Les clés d'API et les fichiers .env dans les commits vivent pour toujours, même après une « suppression » ultérieure. Ajoutez une entrée .gitignore avant le premier commit, et faites tourner immédiatement tout identifiant divulgué. Des outils comme git-secrets et gitleaks peuvent s'exécuter comme hooks pre-commit.

Force-pusher sur les coéquipiers

git push --force réécrit l'historique sur le remote, supprimant les commits des autres. Préférez --force-with-lease, qui refuse d'écraser si le remote a bougé :

git push --force-with-lease

Mal comprendre pull

git pull est fetch + merge (ou rebase). L'exécuter avec des changements non commités peut produire des merge commits surprenants. Soit vous commitez, stashez, soit vous définissez un défaut sensé :

git config --global pull.rebase true
git config --global pull.ff only

Éditer en HEAD détaché sans s'en rendre compte

Faire un checkout d'un tag ou d'un hachage de commit vous laisse en HEAD détaché. Les nouveaux commits y sont inatteignables une fois que vous changez de branche. Créez toujours une branche d'abord :

git switch -c hotfix v1.2.3

Confondre reset, revert et restore

• git restore change l'arborescence de travail ou l'index ; sûr.
• git revert crée un nouveau commit qui en annule un autre ; sûr et partageable.
• git reset --hard déplace la branche et abandonne le travail ; destructif.

Commiter des fichiers énormes

Une vidéo de 500 Mo dans un commit est permanente. Utilisez Git LFS pour les binaires au-delà de quelques mégaoctets, et gardez les artefacts de build entièrement hors du dépôt.

Trousse de récupération

git reflog
git fsck --lost-found
git stash list

Le reflog enregistre chaque mouvement de HEAD pendant 90 jours par défaut ; presque tout commit « perdu » peut en être récupéré.

Mal lire le status

La sortie de git status a des couches subtiles. « Changes not staged for commit » signifie des fichiers suivis modifiés dans l'arborescence de travail. « Changes to be committed » signifie stagés. « Untracked files » signifie que Git ne les a jamais vus. Confusion fréquente : éditer un fichier après l'avoir stagé l'affiche dans les deux listes avec un contenu différent ; seul ce qui est stagé va dans le commit. Exécutez git diff (working vs index) et git diff --staged (index vs HEAD) jusqu'à ce que les trois zones deviennent évidentes.

git status -sb
git diff --staged --stat

Erreurs fréquentes

Paniquer et exécuter rm -rf .git quand quelque chose semble anormal. Stop. Faites d'abord une sauvegarde du répertoire. Presque toute erreur Git est récupérable via le reflog ou le stash. L'habitude la plus importante pour les débutants : exécuter git status avant et après chaque commande qui change l'état, et exécuter git log --oneline --all --graph quand quelque chose semble bizarre.