Aller au contenu principal

Récap et FAQ

Résumé : cette dernière leçon condense les 5 précédentes en une image, répond aux 12 questions pratiques les plus fréquentes des débutants (utiles à la fois pour lever les derniers doutes et pour le référencement Google), et vous oriente vers la suite.

1. Ce que vous savez maintenant​

Vous n'êtes pas encore un utilisateur autonome de Git. Mais vous savez exactement comment ça se passe dans une équipe qui fait bien les choses. C'est la moitié du chemin.

2. FAQ · les 12 questions pratiques des débutants​

2.1 J'ai fait un mauvais commit. Puis-je l'annuler ?​

Oui, presque toujours. Trois cas :

  • Le commit n'est pas encore poussé — vous pouvez le modifier ou le supprimer localement, personne ne le saura.
  • Le commit est poussé mais personne ne l'a récupéré — vous pouvez le supprimer et forcer le push (dangereux, à éviter si vous n'êtes pas seul·e).
  • Le commit est poussé et intégré — vous pouvez faire un nouveau commit qui annule l'ancien (git revert). L'historique reste, mais l'effet est neutralisé.

Règle d'or : ne jamais modifier un commit déjà partagé. Toujours en créer un nouveau qui corrige.

2.2 Puis-je supprimer une branche ?​

Oui, sans hésiter, une fois qu'elle a été fusionnée ou abandonnée. Deux commandes suffisent :

  • git branch -d nom-branche — supprime la branche locale.
  • git push origin --delete nom-branche — supprime la branche distante.

Sur GitHub, un bouton « Delete branch » apparaît automatiquement après la fusion d'une PR.

2.3 C'est quoi git stash et à quoi ça sert ?​

git stash est un tiroir temporaire. Il permet de ranger vos modifications en cours sans les commit, pour changer rapidement de contexte (par exemple, quelqu'un a un bug urgent à corriger et vous n'avez pas fini votre travail).

Une fois le contexte terminé, git stash pop remet vos modifications exactement où elles étaient. C'est une bouée de sauvetage bien connue.

2.4 Le fameux git push --force est-il si dangereux ?​

Oui, très. Un push --force réécrit l'historique distant — si un collègue avait récupéré votre branche avant, ses commits disparaissent au prochain pull.

Règle absolue : ne faites jamais git push --force sur une branche partagée (surtout pas main ni develop). Sur votre branche personnelle avant relecture, c'est acceptable — utilisez plutôt --force-with-lease, une version plus sûre qui refuse si quelqu'un d'autre a poussé entretemps.

2.5 Comment ignorer un fichier (mot de passe, fichier généré) ?​

Créez un fichier nommé .gitignore à la racine du projet, listez-y les fichiers ou dossiers à exclure :

node_modules/
.env
*.log
.DS_Store
build/

Git ne les suivra jamais. Attention : un fichier déjà commit continue d'être suivi même s'il est ajouté au .gitignore — il faut le sortir explicitement avec git rm --cached.

Best-of : le site gitignore.io génère automatiquement un .gitignore complet pour votre langage (Python, Node, Java, Rust…).

2.6 Comment récupérer un fichier que j'ai supprimé par erreur ?​

Tant que le fichier était suivi par Git, il n'est jamais vraiment perdu. Tapez git checkout HEAD -- chemin/du/fichier pour restaurer sa version du dernier commit.

Si le fichier n'était jamais commit et que vous l'avez effacé, Git ne peut rien faire — d'où l'importance de committer souvent.

2.7 C'est quoi la différence entre pull et fetch ?​

  • git fetch = regarder ce qu'il y a de neuf sur le distant, sans rien intégrer.
  • git pull = git fetch suivi de git merge → intègre directement les nouveautés.

Recommandation : préférez fetch puis inspection (git log), puis merge conscient. pull est plus rapide mais parfois surprenant, notamment quand quelqu'un a réécrit l'historique.

2.8 Comment renommer un commit récent ?​

git commit --amend permet de modifier le dernier commit — son message, ses fichiers, ou les deux. C'est très pratique juste après une faute de frappe dans un message.

Attention : ne faites --amend que sur un commit non encore poussé, sinon vous cassez l'historique distant.

2.9 Combien de branches puis-je avoir en même temps ?​

Techniquement, autant que vous voulez — Git supporte des milliers de branches sans broncher. Pragmatiquement, chaque développeur travaille sur 1 à 3 branches à la fois. Au-delà, on perd le fil.

Sur un projet d'équipe, le nombre de branches actives est un bon indicateur : trop de branches ouvertes = accumulation de travail non fusionné = risque de conflits massifs plus tard.

2.10 Puis-je réécrire l'histoire d'un projet ?​

Oui, avec rebase interactif (git rebase -i) — on peut réordonner, fusionner, séparer, renommer, supprimer des commits. C'est très puissant, très dangereux, et à réserver aux branches personnelles avant partage.

Règle sacrée : ne jamais réécrire l'histoire d'une branche partagée. C'est comme changer le passé d'un livre après qu'il ait été distribué — les lecteurs se retrouvent avec des versions incohérentes.

2.11 Comment voir qui a écrit une ligne de code, et pourquoi ?​

git blame chemin/du/fichier affiche, pour chaque ligne, le commit qui l'a introduite, son auteur, sa date, et son message.

C'est un outil essentiel pour comprendre l'histoire d'un projet — souvent une ligne étrange devient claire quand on lit le commit qui l'a créée. Les IDE modernes (VS Code, JetBrains) affichent le blame en direct dans la marge, appelé « CodeLens ».

2.12 Puis-je utiliser Git pour autre chose que du code ?​

Oui, tout à fait. Git est un gestionnaire de fichiers avec historique — il peut versionner :

  • De la documentation (Markdown, LaTeX).
  • Des configurations serveur (Nginx, Apache, systemd, Ansible).
  • Des manuscrits — beaucoup d'écrivains professionnels versionnent leurs romans dans Git.
  • Des recettes de cuisine, des notes personnelles, des fichiers de projet Unity…

Attention : Git est moins performant sur les fichiers binaires très volumineux (photos, vidéos, bases de données) — pour ceux-là, préférez Git LFS (Large File Storage) ou un système de stockage dédié.

3. Aller plus loin​

Trois directions possibles.

Direction 1 · Passer à la pratique complète (recommandé)​

Le Cours Premium Git couvre tous les concepts vus ici avec les vraies commandes :

  • Installation et configuration détaillée.
  • Les 20 commandes essentielles avec exercices.
  • Branches, merge, rebase, cherry-pick, stash, tags.
  • Résolution de conflits avec des mises en situation réelles.
  • Workflows d'équipe (GitHub Flow, GitFlow, Trunk-based).
  • Contribution à un premier projet open source.
  • Bonnes pratiques : Conventional Commits, signatures GPG, hooks.

Compter 30 à 40 heures de contenu structuré avec exercices.

Direction 2 · Explorer les briques adjacentes​

Ce cours pratique a des cousins directs dans le parcours découverte :

Direction 3 · Contribuer à votre premier projet open source​

Le meilleur apprentissage se fait en pratiquant sur un vrai projet. Deux ressources pour commencer aujourd'hui :

Une simple correction de faute de frappe dans une documentation devient votre première pull request, sans stress. Le temps que vous mettiez à faire cette contribution vous surprendra — souvent moins d'une heure.

4. Une dernière image à emporter​

Retenir en 30 secondes​

  • Vous avez maintenant la carte mentale complète de Git en pratique.
  • Prochaine étape recommandée : le Cours Premium Git pour passer aux commandes réelles.
  • Ou ouvrez votre première pull request sur un projet open source dès aujourd'hui — c'est plus accessible qu'on ne le croit.

Félicitations, vous avez terminé le cours découverte Git en pratique.

Prêt·e pour la maîtrise complète ? Découvrir le Cours Premium Git →

Envie de vous mesurer à l'open source ? Trouver un premier ticket accessible →

Explorer les autres bases ? Voir tous les cours découverte →

Dernière étape : passez le quiz de fin de cours — cinq questions corrigées et expliquées, trois minutes, pour vérifier que l'essentiel est acquis.