Git
Debutant
Quiz-Git-Debutant
Git-Commit
Git-Branche
Controle-De-Version
Entretien-Git-Debutant
Qcm-Git
Apprendre-Git
Git-Clone
Git-Push
Git-Pull
Git-Status
📝
Entretien Git Débutant — Commits, Branches et Remote
Testez vos bases Git avec 20 questions niveau débutant : init, add, commit, branches, clone, push et pull. Parfait pour réussir votre premier entretien dev.
Banque de révision : les 60 questions corrigées
Voici l'intégralité des 60 questions de « Entretien Git Débutant — Commits, Branches et Remote », chacune avec sa bonne réponse et son explication. Le quiz interactif ci-dessus en tire une sélection aléatoire à chaque tentative — utilisez cette liste complète pour réviser.
Explication :
Git est un système de contrôle de version distribué (DVCS) créé par Linus Torvalds en 2005. Il permet de suivre l'historique des modifications d'un projet et de collaborer à plusieurs. Chaque développeur possède une copie complète du dépôt en local.
Git = "Gestionnaire d'Instantanés Temporels" : il photographie ton projet à chaque commit.
Explication :
Git est le logiciel de contrôle de version installé sur ta machine. GitHub est une plateforme en ligne qui héberge des dépôts Git et ajoute des fonctionnalités collaboratives (issues, pull requests, etc.). On peut utiliser Git sans GitHub, et il existe des alternatives comme GitLab ou Bitbucket.
Git est l'outil, GitHub est l'un des endroits où tu ranges ton travail.
Explication :
Un VCS (Version Control System) enregistre les changements apportés aux fichiers au fil du temps. Il permet de revenir à une version antérieure, de comparer des modifications et de travailler à plusieurs sans écraser le travail des autres. Git en est l'exemple le plus répandu.
Un VCS, c'est comme une machine à remonter le temps pour ton code.
Explication :
La commande
git init initialise un nouveau dépôt Git en créant un dossier caché .git dans le répertoire courant. Ce dossier contient toute la base de données et la configuration du dépôt. C'est la première étape pour versionner un projet existant.
init = "initialiser" : tu démarres le suivi de version dans ce dossier.
Explication :
La commande
git config --global user.name "Ton Nom" définit ton nom pour tous les dépôts de ta machine grâce à l'option --global. Ce nom apparaîtra comme auteur de chaque commit. Sans --global, la configuration ne s'applique qu'au dépôt courant.
--global = "pour partout" ; sans lui, c'est juste pour le projet actuel.
Explication :
On utilise
git config --global user.email "toi@exemple.com" pour associer une adresse e-mail à tes commits. Avec le nom d'utilisateur, c'est une configuration indispensable avant de réaliser ton premier commit. L'e-mail relie tes commits à ton compte GitHub ou GitLab.
Nom + e-mail : le duo à configurer une seule fois avant de commiter.
Explication :
La commande
git status affiche l'état du répertoire de travail et de la zone d'index. Elle indique les fichiers modifiés, ceux ajoutés à l'index et ceux non suivis (untracked). C'est la commande à exécuter le plus souvent pour savoir où on en est.
En cas de doute, tape git status : c'est ton tableau de bord.
Explication :
La commande
git add fichier.txt place le fichier dans la zone de staging (aussi appelée index). Cela prépare ses modifications pour le prochain commit. Tant qu'un fichier n'est pas ajouté, ses changements ne seront pas enregistrés par git commit.
add = "préparer" : tu poses le fichier dans la file d'attente du commit.
Explication :
La commande
git add . ajoute à la zone de staging tous les fichiers modifiés, nouveaux ou supprimés du répertoire courant et de ses sous-dossiers. Le point représente le dossier courant. C'est pratique mais il faut vérifier avec git status ce qui sera réellement indexé.
Le point . signifie "ici et en dessous" : tout le dossier courant.
Explication :
La commande
git commit -m "message" crée un commit, c'est-à-dire un instantané des fichiers présents dans l'index. L'option -m permet de fournir directement le message décrivant la modification. Sans -m, Git ouvre un éditeur de texte pour saisir le message.
commit = "valider" : tu graves un point de sauvegarde dans l'historique.
Explication :
Git organise le travail en trois zones : le répertoire de travail (working directory) où tu modifies les fichiers, la zone de staging (index) où tu prépares les changements, et le dépôt (repository) où les commits sont stockés de façon permanente.
Working → Staging → Repository : le parcours d'un changement.
Explication :
La zone de staging est aussi appelée l'index. C'est une zone intermédiaire entre le répertoire de travail et le dépôt. On y dépose les modifications que l'on souhaite inclure dans le prochain commit grâce à
git add.
Staging area = index : deux noms pour la même salle d'attente.
Explication :
Le fichier
.gitignore indique à Git quels fichiers et dossiers ne doivent pas être suivis. On y place généralement les dossiers générés comme node_modules/, les fichiers de logs ou les fichiers de configuration sensibles. Cela évite de versionner des fichiers inutiles ou confidentiels.
.gitignore = la liste noire : tout ce qui y figure reste hors de Git.
Explication :
Dans
.gitignore, le motif *.log utilise l'astérisque comme joker. Il fait correspondre tous les fichiers dont le nom se termine par .log. Ces fichiers seront alors ignorés par Git et n'apparaîtront pas dans git status comme non suivis.
L'astérisque * remplace n'importe quelle suite de caractères.
Explication :
La commande
git log affiche la liste des commits du plus récent au plus ancien. Pour chaque commit, elle indique le SHA, l'auteur, la date et le message. C'est la commande de référence pour explorer l'historique d'un projet.
log = "journal" : la liste chronologique de tous tes commits.
Explication :
L'option
git log --oneline condense l'affichage : chaque commit tient sur une seule ligne avec son SHA abrégé et son message. C'est très pratique pour avoir une vue d'ensemble rapide de l'historique sans détails superflus.
--oneline = "une ligne par commit" : vue résumée de l'historique.
Explication :
Le SHA (ou hash) est un identifiant unique de 40 caractères hexadécimaux généré par Git pour chaque commit. Il sert d'empreinte digitale : deux commits différents auront toujours des SHA différents. On utilise souvent une version abrégée (7 caractères) pour désigner un commit.
Le SHA, c'est la carte d'identité unique d'un commit.
Explication :
La commande
git diff affiche les différences entre le répertoire de travail et la zone de staging, c'est-à-dire les modifications non encore indexées. Les lignes ajoutées sont précédées d'un + et les lignes supprimées d'un -.
git diff = "qu'ai-je changé depuis ?" avant de faire git add.
Explication :
La commande
git branch feature crée une nouvelle branche nommée feature à partir du commit courant. Attention : elle ne bascule pas dessus, elle ne fait que la créer. Pour créer et basculer en une seule fois, on utilise git checkout -b feature ou git switch -c feature.
git branch nom : crée la branche mais ne t'y déplace pas.
Explication :
La commande
git branch sans argument liste toutes les branches locales. La branche courante est précédée d'un astérisque * et souvent affichée en couleur. Pour voir aussi les branches distantes, on ajoute l'option -a.
git branch tout court = la liste ; l'étoile marque où tu es.
Explication :
La commande
git switch branche a été introduite pour basculer vers une branche existante de façon claire. Elle remplace une partie des usages de git checkout, jugé trop polyvalent. On peut écrire git switch -c nouvelle pour créer une branche et y basculer en même temps.
switch = "changer de branche" : plus clair que checkout.
Explication :
La commande
git checkout -b nouvelle combine deux actions : elle crée la branche nouvelle et y bascule immédiatement. L'option -b signifie « branch ». C'est l'équivalent de git switch -c nouvelle avec la syntaxe moderne.
checkout -b = créer + se déplacer en une seule commande.
Explication :
La commande
git branch -d nom-branche supprime une branche locale, à condition qu'elle ait déjà été fusionnée. Si la branche contient du travail non fusionné, Git refuse et propose -D (majuscule) pour forcer la suppression.
-d minuscule = suppression sûre ; -D majuscule = suppression forcée.
Explication :
HEAD est un pointeur spécial qui indique le commit (ou la branche) sur lequel tu travailles actuellement. En général, HEAD pointe vers la branche courante, qui pointe elle-même vers son dernier commit. C'est la position de référence pour la plupart des opérations.
HEAD = "tu es ici" : il marque ta position dans l'historique.
Explication :
Exécutée depuis
main, la commande git merge feature intègre les modifications de la branche feature dans main. Si main n'a pas changé depuis la création de feature, Git réalise une fusion fast-forward en avançant simplement le pointeur.
On se place sur la branche qui reçoit, puis on merge la branche source.
Explication :
Une fusion fast-forward se produit quand la branche cible n'a reçu aucun nouveau commit depuis la création de la branche à fusionner. Git se contente alors de faire avancer le pointeur de la branche cible jusqu'au dernier commit, sans créer de commit de merge.
Fast-forward = ligne droite : Git avance le pointeur, sans détour.
Explication :
La commande
git clone url-du-depot télécharge une copie complète d'un dépôt distant, avec tout son historique, sur ta machine. Elle crée automatiquement un dossier, configure le dépôt distant origin et bascule sur la branche principale.
clone = "cloner" : tu récupères une copie complète et autonome.
Explication :
Par convention, le dépôt distant par défaut s'appelle
origin. C'est le nom attribué automatiquement par git clone au dépôt depuis lequel tu as cloné. Ce n'est qu'un alias : on peut en ajouter d'autres ou le renommer.
origin = "l'origine" : le dépôt distant d'où vient ton clone.
Explication :
La commande
git remote -v affiche les dépôts distants configurés ainsi que leurs URLs. L'option -v signifie « verbose » (détaillé). On y voit généralement origin avec une URL pour le fetch et une pour le push.
git remote -v : le carnet d'adresses de tes dépôts distants.
Explication :
La commande
git push envoie les commits de ta branche locale vers le dépôt distant. C'est ainsi que tu partages ton travail avec les autres. Lors du premier envoi d'une branche, on utilise souvent git push -u origin nom-branche pour établir le suivi.
push = "pousser" : tu envoies ton travail vers le distant.
Explication :
La commande
git pull récupère les modifications du dépôt distant et les fusionne immédiatement dans ta branche locale. Elle équivaut à un git fetch suivi d'un git merge. C'est la commande pour mettre à jour ton travail.
pull = "tirer" : tu récupères le travail des autres dans ta branche.
Explication :
git fetch télécharge les nouveautés du dépôt distant sans les fusionner dans ta branche : tu peux les inspecter avant. git pull fait la même chose mais enchaîne automatiquement avec un git merge. Fetch est donc plus prudent.
fetch = "regarder sans toucher" ; pull = "regarder puis fusionner".
Explication :
La commande
git restore fichier.txt remet le fichier dans l'état du dernier commit, annulant ainsi les modifications non indexées. C'est la commande moderne ; l'ancienne syntaxe équivalente est git checkout -- fichier.txt. Attention, ces changements sont perdus.
git restore = la gomme : il efface tes modifications non sauvegardées.
Explication :
L'ancienne syntaxe
git checkout -- fichier.txt annule les modifications non indexées d'un fichier en le restaurant depuis le dernier commit. Le double tiret -- indique à Git qu'on parle d'un fichier et non d'une branche. La syntaxe moderne est git restore.
Le -- sépare les options du nom de fichier pour éviter toute ambiguïté.
Explication :
La commande
git rm fichier.txt supprime le fichier du disque et le retire de l'index. La suppression sera enregistrée au prochain commit. Pour le retirer du suivi de Git mais le garder sur le disque, on utilise git rm --cached fichier.txt.
git rm supprime le fichier ET prépare la suppression pour le commit.
Explication :
La commande
git mv ancien.txt nouveau.txt renomme ou déplace un fichier et met automatiquement à jour l'index. C'est un raccourci équivalent à renommer le fichier manuellement puis exécuter git rm et git add.
git mv = "move" : renommer ou déplacer en informant Git d'un coup.
Explication :
La commande
git show affiche les détails d'un commit : son SHA, son auteur, sa date, son message et le diff des modifications qu'il contient. Sans argument, elle montre le dernier commit ; on peut aussi lui passer un SHA précis.
git show : zoom complet sur ce qu'un commit a changé.
Explication :
Le fichier
README (souvent README.md en Markdown) présente le projet : son objectif, son installation, son utilisation et parfois la façon de contribuer. Sur GitHub, son contenu s'affiche automatiquement sur la page d'accueil du dépôt.
Le README est la vitrine du projet : la première chose qu'on lit.
Explication :
Un fork est une copie d'un dépôt existant créée sur ton propre compte GitHub. Il te permet d'expérimenter ou de contribuer librement sans toucher au projet d'origine. Tu peux ensuite proposer tes modifications via une pull request.
Le fork, c'est ta copie perso d'un projet, sur ton compte GitHub.
Explication :
La commande
git help affiche l'aide intégrée de Git. Pour obtenir l'aide d'une commande précise, on écrit par exemple git help commit ou git commit --help, qui ouvre la documentation détaillée de cette commande.
Bloqué ? git help ouvre la doc officielle de la commande.
Explication :
Un fichier qui existe dans le répertoire de travail mais que Git ne suit pas encore est qualifié de untracked (non suivi) dans
git status. Pour commencer à le suivre, il faut l'ajouter à l'index avec git add.
untracked = "inconnu de Git" : il faut un git add pour le suivre.
Explication :
Un message de commit clair permet à toute l'équipe de comprendre pourquoi une modification a été faite, sans relire tout le code. Un bon message décrit l'intention du changement. Cela facilite la relecture, le débogage et la maintenance du projet sur le long terme.
Écris ton message comme une note pour ton "toi" du futur.
Explication :
La commande
git switch -c ma-branche crée une nouvelle branche et y bascule immédiatement. L'option -c signifie « create ». C'est l'équivalent moderne de git checkout -b ma-branche, avec une syntaxe plus lisible.
switch -c = "create and switch" : nouvelle branche + déplacement.
Explication :
Un commit est un instantané (snapshot) de l'état du projet à un instant donné. Il enregistre les fichiers de l'index, accompagné d'un message, d'un auteur, d'une date et d'un identifiant SHA. L'enchaînement des commits forme l'historique du projet.
Un commit = une photo de ton projet à un instant T.
Explication :
La commande
git config --global --list affiche tous les paramètres de la configuration globale, comme user.name et user.email. Sans --global, git config --list montre la configuration combinée applicable au dépôt courant.
--list = "montre-moi tout" : pratique pour vérifier ta config.
Explication :
Si tu modifies un fichier suivi sans faire
git add, il apparaît comme modified dans git status, mais ses changements restent dans le répertoire de travail. Ils ne seront pas inclus dans le prochain commit tant qu'ils ne sont pas indexés.
Pas de git add = pas dans le commit : l'index est obligatoire.
Explication :
La commande
git diff --staged (ou git diff --cached) montre les différences entre la zone de staging et le dernier commit, c'est-à-dire ce qui sera inclus dans le prochain commit. C'est utile pour relire ses changements juste avant de commiter.
git diff seul = non indexé ; git diff --staged = déjà indexé.
Explication :
Lors d'un
git init, Git crée un dossier caché nommé .git à la racine du projet. Ce dossier contient toute la base de données du dépôt : les commits, les branches, la configuration et l'index. Si on le supprime, le projet n'est plus versionné.
Le dossier .git est le cerveau du dépôt : ne le supprime jamais.
Explication :
Git est distribué car chaque clone du dépôt contient l'intégralité de l'historique et des fichiers. Tu peux donc commiter, créer des branches et consulter l'historique hors ligne. Contrairement aux systèmes centralisés, aucun serveur unique n'est indispensable au quotidien.
Distribué = chacun a une copie complète, autonome et hors ligne.
Explication :
La zone de staging sert à composer le prochain commit. Plutôt que de tout enregistrer d'un bloc, tu choisis avec
git add exactement quelles modifications inclure. Cela permet de créer des commits ciblés et cohérents, même si tu as modifié plusieurs fichiers.
Le staging te laisse trier ce qui entre, ou non, dans le commit.
Explication :
La commande
git push -u origin main envoie la branche main vers origin et, grâce à l'option -u (upstream), établit le lien de suivi. Les prochaines fois, un simple git push ou git pull suffira sans préciser la branche.
-u une seule fois : ensuite git push/pull tout court suffisent.
Explication :
La commande
git rm --cached fichier.txt retire le fichier du suivi de Git tout en le conservant sur le disque. C'est utile quand on a versionné par erreur un fichier qui aurait dû être dans .gitignore.
--cached = "juste de l'index" : le fichier reste sur ton disque.
Explication :
La commande
git fetch récupère les commits, branches et tags du dépôt distant sans toucher à ta branche locale ni à tes fichiers. Tu peux ensuite examiner les changements et décider de les fusionner avec git merge si tu le souhaites.
fetch = "aller chercher sans appliquer" : 100 % sans risque.
Explication :
Une branche est une ligne de développement indépendante. Techniquement, c'est un pointeur léger vers un commit. Les branches permettent de travailler sur une nouvelle fonctionnalité ou un correctif sans perturber la branche principale, avant de fusionner le résultat.
Une branche = un chemin de travail parallèle, isolé du reste.
Explication :
En passant un nom de fichier à
git log, comme git log index.html, on affiche uniquement les commits ayant modifié ce fichier. C'est très pratique pour retracer l'évolution d'un fichier précis dans un gros projet.
git log : l'histoire d'un seul fichier, filtrée.
Explication :
Le flux de base consiste à indexer puis valider :
git add fichier.txt
git commit -m "Ajout de la fonctionnalité"
On place d'abord les changements dans l'index avec
git add, puis on les enregistre dans le dépôt avec git commit.
Toujours dans l'ordre : add (préparer) puis commit (valider).
Explication :
Sans l'option
-m, git commit ouvre l'éditeur de texte configuré (souvent Vim ou Nano) pour que tu saisisses le message du commit. Si tu enregistres un message vide et fermes l'éditeur, Git annule le commit.
Pas de -m ? Git te laisse écrire un message plus long dans l'éditeur.
Explication :
Après un
git init ou un git clone, on se trouve sur la branche principale du projet. Sur les versions récentes de Git, elle s'appelle souvent main ; sur les anciens dépôts, c'est généralement master. C'est la branche par défaut.
main (récent) ou master (ancien) : la branche par défaut du projet.
Explication :
L'option
--global de git config enregistre le paramètre pour tous les dépôts de l'utilisateur courant, dans son fichier .gitconfig personnel. Sans cette option, le réglage ne s'applique qu'au dépôt en cours.
--global = "pour tous mes projets" ; rien = "ce projet seulement".
Explication :
Des commits petits et fréquents rendent l'historique lisible : chaque commit représente un changement précis. En cas de problème, il est plus simple d'identifier et d'annuler la modification fautive. Cela facilite aussi la relecture du code par l'équipe.
Un commit = une idée : petit, ciblé et facile à comprendre.