Français
Menu

Qu'est-ce que Git ?

Système de gestion de versions distribué qui enregistre et gère l'historique des modifications des fichiers. Les modifications faites dans le répertoire de travail sont enregistrées dans la zone de préparation avec git add, enregistrées dans le dépôt local avec git commit, et envoyées vers un dépôt distant comme GitHub avec git push. Les branches permettent un développement en parallèle et s'intègrent avec git merge. Outre le code source, Git sert aussi à gérer le RTL, les bancs de test de vérification, les scripts, etc.

Nom japonais: Git

« Git » apparaît dans 6 questions d'entraînement réparties sur 3 thèmes, dont Bases de Linux et de la ligne de commande, Développement logiciel et gestion de projet, Bases du cloud et des conteneurs.

Domaine: Bases de Linux et de la ligne de commande

Les trois emplacements

Git distingue le répertoire de travail, où l'on modifie les fichiers, la zone de préparation (l'index), qui contient les modifications à inclure dans le prochain commit, et le dépôt (le répertoire .git), qui conserve l'historique des commits. git status montre les différences entre ces trois emplacements ; git diff affiche la différence entre le répertoire de travail et la zone de préparation, et git diff --staged celle entre la zone de préparation et le dernier commit.

Branches et dépôts distants

Une branche est un nom donné à une bifurcation de l'historique des commits ; elle permet d'avancer sur de nouvelles fonctions ou des corrections sans toucher à la branche principale. git clone copie localement un dépôt distant, git pull récupère les nouveaux commits du dépôt distant, et git push envoie ses propres commits. Fusionner des branches qui ont modifié séparément le même endroit produit un conflit qu'une personne doit résoudre.

Ce qu'il ne faut pas suivre

Les fichiers produits par les compilations et les simulations, les journaux, les grosses données de formes d'onde et autres sont écrits dans .gitignore pour les exclure du suivi. Un fichier déjà validé reste suivi même s'il est écrit dans .gitignore : on le retire donc avec git rm --cached. Un mot de passe ou une clé validés par erreur restent dans l'historique : il est donc important de prendre l'habitude de vérifier le contenu avec git status et git diff avant chaque commit.

S'entraîner : questions sur Git

Après avoir modifié main.c, un fichier géré avec Git, on a seulement exécuté « git commit -m "fix" » : « no changes added to commit » s'est affiché et rien n'a été validé. Quelle en est la raison ?

  1. AAvant de valider (commit), il faut envoyer les modifications vers le dépôt partagé avec git push
  2. BLes modifications à inclure dans un commit doivent d'abord être enregistrées dans la zone de préparation (staging area) avec git add
  3. CGit valide automatiquement à chaque enregistrement d'un fichier, si bien qu'il n'est pas nécessaire d'exécuter git commit
Afficher la réponse et l'explication

Réponse : B. Les modifications à inclure dans un commit doivent d'abord être enregistrées dans la zone de préparation (staging area) avec git add

Dans Git, parmi les modifications faites dans le répertoire de travail, seules celles qui ont été enregistrées dans la zone de préparation (l'index) avec git add sont enregistrées par le git commit suivant. Ce mécanisme en deux étapes permet de choisir, parmi plusieurs modifications, seulement celles qui vont ensemble pour en faire un seul commit. git status montre quelles modifications sont dans la zone de préparation. Il existe aussi la forme git commit -a, qui ajoute d'un coup toutes les modifications des fichiers suivis et les valide.

On a exécuté git commit dans Git, mais le commit n'apparaît pas encore dans le dépôt GitHub partagé par l'équipe. Quelle en est la raison ?

  1. Agit commit ne fait qu'enregistrer les modifications dans la zone de préparation, et git add est nécessaire pour les valider
  2. BPour envoyer les modifications validées vers le dépôt partagé, il faut exécuter git pull
  3. Cgit commit enregistre dans le dépôt local, et git push est nécessaire pour l'envoyer vers le dépôt distant
Afficher la réponse et l'explication

Réponse : C. git commit enregistre dans le dépôt local, et git push est nécessaire pour l'envoyer vers le dépôt distant

Git est un système de gestion de versions distribué dans lequel chaque développeur possède localement le dépôt complet, et git commit enregistre les modifications dans ce dépôt local. Pour les envoyer vers un dépôt distant comme GitHub, on exécute git push ; à l'inverse, git pull (ou git fetch puis git merge) récupère dans le dépôt local les nouveaux commits du dépôt distant. C'est pourquoi on peut faire des commits sans connexion réseau et les envoyer ensemble plus tard avec push. Si quelqu'un d'autre a fait un push avant, on peut être invité à intégrer d'abord ses modifications.

Questions fréquentes

Quelle différence y a-t-il entre Git et GitHub ?

Git est le logiciel de gestion de versions lui-même, qui s'exécute sur son propre ordinateur. GitHub est un service web qui héberge des dépôts Git et y ajoute des fonctions comme la revue par pull requests et la gestion des tickets. Il existe des services semblables comme GitLab, ainsi que des serveurs installés dans l'entreprise, et Git lui-même peut s'utiliser avec n'importe lequel d'entre eux.

Comment annuler le dernier commit ?

S'il n'a pas encore été envoyé avec push, git commit --amend permet de corriger le dernier commit, et git reset de l'annuler. Pour un commit déjà envoyé et partagé, il est plus sûr d'utiliser git revert, qui ajoute la modification d'annulation sous la forme d'un nouveau commit, afin de ne pas entrer en conflit avec l'historique des autres.

« Git » dans les explications

Questions mentionnant « Git » (6)

  1. Après avoir modifié main.c, un fichier géré avec Git, on a seulement exécuté « git commit -m "fix" » : « no changes added to commit » s'est affiché et rien n'a été validé. Quelle en est la raison ?
  2. On a exécuté git commit dans Git, mais le commit n'apparaît pas encore dans le dépôt GitHub partagé par l'équipe. Quelle en est la raison ?
  3. Dans un projet géré avec Git, on a écrit « build/ » dans le fichier .gitignore, mais les modifications de build/out.log, qui avait été validé auparavant, continuent d'apparaître dans git status. Quelle en est la raison ?
  4. Avec Git, deux développeurs ont modifié la même ligne du même fichier sur des branches différentes, puis l'une des branches a été fusionnée dans l'autre. Que se passe-t-il ?
  5. Après une version de micrologiciel dont on sait qu'elle fonctionne correctement, il y a 1000 commits, et le dernier commit présente un bogue. Le bogue a été introduit par un commit et se produit dans tous les commits suivants. Quand on identifie le commit fautif par recherche dichotomique, comme avec git bisect, combien de fois au maximum faut-il compiler et tester le micrologiciel ?
  6. Un environnement a été créé en appliquant, avec un outil d'IaC (infrastructure en tant que code) déclaratif, un fichier qui définit un réseau et deux machines virtuelles. Juste après, on applique de nouveau le même fichier sans rien modifier. Que se passe-t-il ?

Termes associés

Recherche dichotomique (recherche binaire) Infrastructure en tant que code (IaC) cron Expression régulière (regex) grep inode Lien physique (hard link) Lien symbolique (symlink) Permissions (droits d'accès) Pipe (|)

Retour au glossaire