Préparation d'entretien 100% Gratuit angularforall.com

Entretien Git Débutant — Commits, Branches et Remote

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
Débutant 🔀 Mixte 20 questions ⏱ 15 min
📝

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.

20 questions ⏱ ~15 min Niveau Débutant

Partager

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.

  • Un système de contrôle de version distribué (bonne réponse)
  • Un langage de programmation web
  • Un service d'hébergement de fichiers en ligne
  • Un éditeur de code source
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.

  • Git est payant, GitHub est gratuit
  • Git est un outil de contrôle de version, GitHub est une plateforme d'hébergement de dépôts (bonne réponse)
  • Git fonctionne uniquement en ligne, GitHub en local
  • Il n'y a aucune différence, ce sont des synonymes
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.

  • À compiler le code source en exécutable
  • À déployer automatiquement une application en production
  • À suivre les modifications du code et à gérer son historique (bonne réponse)
  • À détecter les bugs dans le code automatiquement
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.

  • git start
  • git new
  • git create
  • git init (bonne réponse)
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.

  • git config --global user.name "Ton Nom" (bonne réponse)
  • git set username "Ton Nom"
  • git user --name "Ton Nom"
  • git config name "Ton Nom"
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.

  • git email "toi@exemple.com"
  • git config --global user.email "toi@exemple.com" (bonne réponse)
  • git config --global email "toi@exemple.com"
  • git set email "toi@exemple.com"
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.

  • git state
  • git info
  • git status (bonne réponse)
  • git check
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.

  • Elle crée le fichier fichier.txt sur le disque
  • Elle supprime fichier.txt du dépôt
  • Elle envoie fichier.txt sur le serveur distant
  • Elle ajoute fichier.txt à la zone de staging (index) (bonne réponse)
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.

  • Elle ajoute tous les fichiers modifiés et nouveaux du dossier à l'index (bonne réponse)
  • Elle supprime tous les fichiers du dépôt
  • Elle annule toutes les modifications en cours
  • Elle crée un nouveau dépôt dans le dossier courant
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.

  • git save -m "message"
  • git commit -m "message" (bonne réponse)
  • git push -m "message"
  • git record "message"
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.

  • Le serveur, le client et le cache
  • La branche, le tag et le commit
  • Le répertoire de travail, la zone de staging et le dépôt (bonne réponse)
  • Le clone, le fork et le pull
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.

  • L'index (bonne réponse)
  • Le buffer
  • Le cache distant
  • Le tampon de commit
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.

  • À lister les fichiers que Git doit absolument suivre
  • À indiquer à Git les fichiers et dossiers à ignorer (ne pas suivre) (bonne réponse)
  • À stocker les messages de commit
  • À configurer le nom d'utilisateur du dépôt
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.

  • Elle force le suivi de tous les fichiers .log
  • Elle supprime les fichiers .log du disque
  • Elle ignore tous les fichiers se terminant par .log (bonne réponse)
  • Elle renomme les fichiers .log
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.

  • git history
  • git log (bonne réponse)
  • git commits
  • git list
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.

  • Elle affiche chaque commit de façon compacte, sur une seule ligne (bonne réponse)
  • Elle supprime tous les commits sauf le dernier
  • Elle limite l'affichage à un seul commit
  • Elle affiche uniquement les commits en ligne sur le serveur
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.

  • Le nom de l'auteur du commit
  • Le message décrivant le commit
  • La date de création du commit
  • Un identifiant unique généré pour chaque commit (bonne réponse)
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.

  • git diff (bonne réponse)
  • git changes
  • git status --full
  • git compare
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.

  • git new branch feature
  • git branch feature (bonne réponse)
  • git create feature
  • git checkout feature
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.

  • git branch (bonne réponse)
  • git branches --all
  • git list-branch
  • git show branches
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.

  • git goto branche
  • git switch branche (bonne réponse)
  • git move branche
  • git jump branche
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.

  • Elle supprime la branche nouvelle
  • Elle renomme la branche courante en nouvelle
  • Elle crée la branche nouvelle et bascule dessus (bonne réponse)
  • Elle fusionne la branche nouvelle dans la branche courante
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.

  • git branch -d nom-branche (bonne réponse)
  • git remove nom-branche
  • git branch --erase nom-branche
  • git delete nom-branche
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.

  • Le premier commit du dépôt
  • Un pointeur vers le commit (ou la branche) courant (bonne réponse)
  • Le serveur distant principal
  • Le fichier de configuration global
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.

  • Elle supprime la branche feature
  • Elle copie la branche main dans feature
  • Elle intègre les modifications de la branche feature dans main (bonne réponse)
  • Elle envoie la branche feature sur le serveur distant
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.

  • Une fusion qui crée toujours un commit de merge dédié
  • Une fusion qui supprime l'historique des deux branches
  • Une fusion impossible à réaliser sans conflit
  • Une fusion où Git avance simplement le pointeur sans créer de commit de merge (bonne réponse)
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.

  • git copy url-du-depot
  • git clone url-du-depot (bonne réponse)
  • git download url-du-depot
  • git fetch url-du-depot
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.

  • main
  • master
  • origin (bonne réponse)
  • remote
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.

  • git remote -v (bonne réponse)
  • git remote list
  • git show remote
  • git distant -v
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.

  • Elle télécharge les modifications depuis le dépôt distant
  • Elle envoie tes commits locaux vers le dépôt distant (bonne réponse)
  • Elle supprime les commits du dépôt distant
  • Elle crée une nouvelle branche distante automatiquement
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.

  • Elle envoie tes commits vers le dépôt distant
  • Elle supprime les commits distants
  • Elle récupère les modifications distantes et les fusionne dans ta branche locale (bonne réponse)
  • Elle crée un nouveau dépôt local
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.

  • git fetch récupère les données distantes sans fusionner, git pull récupère et fusionne (bonne réponse)
  • git fetch et git pull font exactement la même chose
  • git fetch envoie les données, git pull les reçoit
  • git fetch fonctionne en local, git pull en distant
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".

  • git delete fichier.txt
  • git restore fichier.txt (bonne réponse)
  • git reset --hard fichier.txt
  • git cancel fichier.txt
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.

  • git revert fichier.txt
  • git undo fichier.txt
  • git checkout -- fichier.txt (bonne réponse)
  • git clean fichier.txt
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é.

  • Elle supprime fichier.txt du disque et de l'index (bonne réponse)
  • Elle renomme fichier.txt
  • Elle restaure fichier.txt depuis le dernier commit
  • Elle envoie fichier.txt sur le dépôt distant
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.

  • Elle copie ancien.txt vers nouveau.txt
  • Elle déplace ou renomme le fichier et enregistre l'opération dans l'index (bonne réponse)
  • Elle fusionne les deux fichiers
  • Elle supprime les deux fichiers
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.

  • Elle affiche la liste des branches
  • Elle affiche les détails d'un commit (message et modifications) (bonne réponse)
  • Elle affiche la configuration globale de Git
  • Elle affiche les fichiers ignorés
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é.

  • À stocker le mot de passe du dépôt
  • À lister les commits du projet
  • À présenter le projet et expliquer comment l'utiliser (bonne réponse)
  • À configurer les branches du dépôt
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.

  • Une copie personnelle d'un dépôt existant sur ton propre compte (bonne réponse)
  • Une branche locale créée avec git branch
  • Un commit qui n'a pas encore été poussé
  • Une fusion entre deux dépôts distants
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.

  • git manual
  • git assist
  • git help (bonne réponse)
  • git doc
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.

  • Un fichier "staged"
  • Un fichier "modified"
  • Un fichier "committed"
  • Un fichier "untracked" (bonne réponse)
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.

  • Parce que Git refuse les messages courts
  • Pour que l'historique reste compréhensible par toute l'équipe (bonne réponse)
  • Parce que le message sert de mot de passe au commit
  • Parce que le message détermine le nom de la branche
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.

  • git switch -c ma-branche (bonne réponse)
  • git switch --new ma-branche
  • git branch -c ma-branche
  • git switch -b ma-branche
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.

  • Une copie de sauvegarde envoyée sur GitHub
  • Un instantané enregistré de l'état du projet à un moment donné (bonne réponse)
  • Un fichier de configuration du dépôt
  • Une branche temporaire
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.

  • git config --global --list (bonne réponse)
  • git settings --all
  • git config --show
  • git global --list
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.

  • La modification est automatiquement incluse au prochain commit
  • Git supprime la modification
  • Le fichier apparaît comme modifié mais ne sera pas inclus au prochain commit (bonne réponse)
  • Git crée automatiquement une nouvelle branche
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.

  • git diff --all
  • git diff --staged (bonne réponse)
  • git diff --index-only
  • git status --diff
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é.

  • Le dossier .config
  • Le dossier .repo
  • Le dossier .vcs
  • Le dossier .git (bonne réponse)
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.

  • Parce que chaque développeur possède une copie complète du dépôt et de son historique (bonne réponse)
  • Parce qu'il faut un serveur central pour pouvoir l'utiliser
  • Parce qu'il distribue automatiquement le code en production
  • Parce qu'il répartit le code sur plusieurs disques durs
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.

  • Elle envoie automatiquement les fichiers sur le serveur
  • Elle compile le code avant l'enregistrement
  • Elle permet de choisir précisément quelles modifications seront incluses dans le commit (bonne réponse)
  • Elle sauvegarde une copie de secours sur le disque
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.

  • Elle supprime la branche main du dépôt distant
  • Elle envoie la branche main et établit le suivi avec la branche distante (bonne réponse)
  • Elle télécharge la branche main depuis le distant
  • Elle renomme la branche main en origin
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.

  • Elle supprime le fichier du disque et de l'index
  • Elle restaure le fichier depuis le dernier commit
  • Elle retire le fichier du suivi de Git mais le conserve sur le disque (bonne réponse)
  • Elle envoie le fichier sur le dépôt distant
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.

  • git fetch (bonne réponse)
  • git pull
  • git merge
  • git push
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.

  • Un fichier de configuration du dépôt
  • Une ligne de développement indépendante au sein du projet (bonne réponse)
  • Une copie du dépôt sur un autre serveur
  • Un message attaché à un commit
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.

  • git history index.html
  • git log index.html (bonne réponse)
  • git show --file index.html
  • git status index.html
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.

  • git commit puis git add
  • git push puis git pull
  • git init puis git status
  • git add puis git commit (bonne réponse)
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).

  • Git ouvre un éditeur de texte pour saisir le message du commit (bonne réponse)
  • Git annule le commit sans rien faire
  • Git crée un commit avec un message vide automatiquement
  • Git affiche une erreur et arrête le programme
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.

  • Sur la branche develop
  • Sur aucune branche
  • Sur la branche principale, souvent nommée main ou master (bonne réponse)
  • Sur la branche origin
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.

  • Elle applique la configuration uniquement au dépôt courant
  • Elle applique la configuration à tous les dépôts de l'utilisateur sur la machine (bonne réponse)
  • Elle envoie la configuration sur le serveur distant
  • Elle réinitialise toute la configuration de Git
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".

  • Parce que Git limite la taille de chaque commit
  • Parce que les gros commits sont automatiquement rejetés
  • Parce que cela rend l'historique plus clair et facilite le retour en arrière (bonne réponse)
  • Parce que cela accélère la connexion au dépôt distant
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.