Inspecter un dépôt grâce à git status
git status
La commande git status
affiche l'état du répertoire de travail et de la zone de staging. Elle vous permet de voir les changements qui ont été stagés, ceux qui ne l'ont pas été, ainsi que les fichiers qui sont trackés par Git. La sortie de l'état n'affichera pas les informations sur l'historique du projet commité. Pour cela, vous devez utiliser git log
.
Commandes Git connexes
- git tag
- Les tags sont des réfs qui pointent vers des points spécifiques de l'historique Git.
git tag
est généralement utilisé pour capturer un point dans l'historique utilisé pour une livraison de version marquée (p. ex., v1.0.1).
- Les tags sont des réfs qui pointent vers des points spécifiques de l'historique Git.
- git blame
git blame
a pour fonction générale d'afficher les métadonnées d'auteur associées à des lignes de commit spécifiques dans un fichier. Cette approche est utilisée pour explorer l'historique d'un code spécifique et répondre aux questions « quel code a été ajouté à un dépôt », « comment » et « pourquoi ».
- Git log
- La commande
git log
affiche les instantanés commités. Elle vous permet de répertorier l'historique du projet, de le filtrer et de rechercher des changements spécifiques.
- La commande
Ressource connexe
Fiche de révision sur Git
DÉCOUVRIR LA SOLUTION
Découvrir Git avec Bitbucket Cloud
Utilisation
git status
Répertorie les fichiers stagés, non stagés et non trackés.
Discussion
La commande git status
est relativement simple. Elle vous montre simplement ce qui se passe avec git add
et git commit
. Les messages d'état comprennent également des instructions pertinentes pour l'indexation/la désindexation des fichiers. Vous trouverez ci-dessous un exemple de sortie affichant les trois catégories principales d'un appel git status
:
# On branch main
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
#modified: hello.py
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
#modified: main.py
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
#hello.pyc
Ignorer des fichiers
Les fichiers non trackés sont généralement répartis en deux catégories. Il peut s'agir de fichiers qui ont simplement été ajoutés au projet et qui n'ont pas encore été commités ou de fichiers binaires compilés comme .pyc
, .obj
, .exe
, etc. Bien qu'il soit sans aucun doute avantageux d'inclure le premier type de fichiers dans la sortie git status
, le second peut créer des difficultés pour voir ce qui se passe réellement dans votre dépôt.
C'est la raison pour laquelle Git vous permet d'ignorer totalement les fichiers en plaçant les chemins dans un fichier spécial nommé .gitignore
. Tous les fichiers que vous souhaitez ignorer doivent figurer sur une ligne distincte, et le symbole * peut être utilisé comme un caractère générique. Par exemple, le fait d'ajouter ce qui suit dans un fichier .gitignore
à la racine de votre projet empêchera les modules Python compilés d'apparaître dans git status
:
*.pyc
Exemple
Il est recommandé de vérifier l'état de votre dépôt avant de commiter les changements pour que vous ne commitiez pas accidentellement quelque chose sans le vouloir. Cet exemple indique l'état du dépôt avant et après le staging et le commit d'un bout de code :
# Edit hello.py
git status
# hello.py is listed under "Changes not staged for commit"
git add hello.py
git status
# hello.py is listed under "Changes to be committed"
git commit
git status
# nothing to commit (working directory clean)
The first status output will show the file as unstaged. The git add
action will be reflected in the second git status
, and the final status output will tell you that there is nothing to commit—the working directory matches the most recent commit. Some Git commands (e.g., git merge) require the working directory to be clean so that you don't accidentally overwrite changes.
Git log
La commande git log
affiche des instantanés commités. Elle vous permet de lister l'historique du projet, de le filtrer et de rechercher des changements spécifiques. Alors que git status
vous permet d'inspecter le répertoire de travail et la zone de staging, git log
fonctionne uniquement sur l'historique commité.
Vous pouvez personnaliser la sortie du journal de différentes manières, par exemple en filtrant simplement les commits ou en les affichant dans un format entièrement définissable par l'utilisateur. Certaines des configurations les plus courantes de git log
sont présentées ci-dessous.
Utilisation
git log
Afficher l'historique complet des commits en utilisant le formatage par défaut. Si la sortie nécessite plusieurs écrans, vous pouvez utiliser Espace
pour faire défiler et q
pour quitter.
git log -n <limit>
Limiter le nombre de commits par
. Par exemple, git log -n 3
affichera seulement trois commits.
Rassemble tous les commits sur une seule ligne. Cette commande est utile pour obtenir un aperçu général de l'historique du projet.
git log --oneline
git log --stat
En plus des informations git log
ordinaires, incluez les fichiers qui ont été modifiés et le nombre relatif de lignes qui ont été ajoutées ou supprimées de chacun d'entre eux.
git log -p
Affiche le patch représentant chaque commit. Cette commande affiche une comparaison complète de tous les commits, c'est la vue la plus détaillée que vous pouvez avoir de votre historique de projet.
git log --author="<pattern>"
Search for commits by a particular author. The <pattern>
argument can be a plain string or a regular expression.
git log --grep="<pattern>"
Search for commits with a commit message that matches <pattern>
, which can be a plain string or a regular expression.
git log <since>..<until>
Affichez uniquement les commits qui surviennent entre
et
. Les deux arguments peuvent être un ID de commit, un nom de branche, un HEAD
ou tout autre type de référence de révision.
git log <file>
Affiche uniquement les commits qui comprennent le fichier spécifié. C'est un moyen facile de voir l'historique d'un fichier spécifique.
git log --graph --decorate --oneline
Quelques options utiles à prendre en compte. L'option --graph dessine un graphique basé sur le texte des commits à gauche des messages de commit. L'option --decorate ajoute les noms des branches ou des options des commits affichés. L'option --oneline indique les informations de commit sur une ligne unique, ce qui offre un aperçu rapide des commits.
Discussion
5. Vérifiez l'état du fichier.
commit 3157ee3718e180a9476bf2e5cab8e3f1e78a73b7
Author: John Smith
Elle est relativement simple, mais la première ligne mérite quelques explications. La chaîne de 40 caractères après commit
est une somme de contrôle SHA-1 du contenu du commit. Elle a deux fonctions. Tout d'abord, elle assure l'intégrité du commit. S'il est corrompu, le commit génère une somme de contrôle différente. Elle sert également d'ID unique pour le commit.
Cet ID peut être utilisé dans des commandes comme git log
pour référencer certains commits. Par exemple, git log 3157e..5ab91
affiche tous les éléments entre les commits dont les ID sont 3157e
et 5ab91
. En dehors des sommes de contrôle, les noms de branche (examinés dans le module Branches) et le mot-clé HEAD sont d'autres méthodes courantes pour référencer des commits individuels. HEAD
renvoie toujours au commit actuel, qu'il s'agisse d'une branche ou d'un commit spécifique.
Le caractère ~ permet de créer des références relatives au parent d'un commit. Par exemple, 3157e~1
renvoie au commit avant 3157e
et HEAD~3
est l'arrière grand-parent du commit actuel.
Exemple
La section Utilisation contient de nombreux exemples de git log
, mais gardez à l'esprit qu'il est possible de combiner plusieurs options dans une commande :
git log --author="John Smith" -p hello.py
Cette commande affichera une comparaison complète de tous les changements apportés par Jean dans le fichier hello.py
.
La syntaxe .. est un outil très utile pour comparer des branches. L'exemple suivant affiche un bref aperçu de tous les commits situés dans some-feature
et en dehors de main
.
git log --oneline main..some-feature
Partager cet article
Thème suivant
Lectures recommandées
Ajoutez ces ressources à vos favoris pour en savoir plus sur les types d'équipes DevOps, ou pour les mises à jour continues de DevOps chez Atlassian.