La commande git log fournit de nombreuses sous-options. Une bonne utilisation de ces options peut accélérer l'efficacité des ingénieurs qui enquêtent sur les problèmes. Ce qui suit utilise le projet ccache comme exemple pour expliquer.
Table des matières
- 1. journal git
- 2. Joli mode [ git log --pretty= ]
- 3. Sortie de ligne unique
- 4. Générez les statistiques du montant de la modification de chaque soumission
- 5. Générez toutes les modifications validées
- 6. Afficher les modifications d'un certain commit [ git show --stat commitID ]
- 7. Afficher le contenu modifié d'un commit [ git show commitID ]
- 8. Spécifiez le format de date [ git log --date= ]
- 9. Filtrer et afficher selon une certaine condition
- 10. Générez l'enregistrement de validation pour chaque ligne du fichier
1. journal git
ID de commit complet, auteur, date de commit, commentaires
2. Joli mode [ git log --pretty= ]
Cette jolie peut être comprise comme un embellissement de la sortie par défaut de git log, comprenant plusieurs sous-options, les utilisateurs peuvent en choisir une en fonction de leurs besoins.
paramètre | illustrer |
---|---|
Journaux de sortie sous forme d'e-mails, ce qui est pratique pour écrire des e-mails | |
complet | Moins de date, plus de committer que le format par défaut |
plus complet | Par rapport au format par défaut, il y a plus de dates d'auteur, de committers, de dates de commit |
moyen | identique au format par défaut |
en ligne | Chaque commit est affiché sur une seule ligne, et git log --oneline comparé à l'identifiant de commit, l'identifiant de commit est complet |
brut | Par rapport au format par défaut, il y a moins de dates et plus de signatures de committers, tree, parent, gpg |
court | Seuls les commentaires de l'auteur et du commit, et les commentaires sont affichés sur une seule ligne |
format: | Format de sortie d'affichage personnalisé |
2.1 git log --pretty=email
2.2 git log --pretty=full
2.3 git log --pretty=fuller
2.4 git log --pretty=moyen
2.5 git log --pretty=oneline
2.6 journal git --pretty=raw
2.7 journal git --pretty=short
2.8 git log --pretty=format :
Il y a trop d'options pour le format, donc je n'entrerai pas dans les détails ici. Ce qui suit est un extrait du manuel. Les lecteurs peuvent apprendre selon leurs propres besoins quand ils ont le temps.
· %H: commit hash
· %h: abbreviated commit hash
· %T: tree hash
· %t: abbreviated tree hash
· %P: parent hashes
· %p: abbreviated parent hashes
· %an: author name
· %aN: author name (respecting .mailmap, see git-shortlog(1) or git-blame(1))
· %ae: author email
· %aE: author email (respecting .mailmap, see git-shortlog(1) or git-blame(1))
· %ad: author date (format respects --date= option)
· %aD: author date, RFC2822 style
· %ar: author date, relative
· %at: author date, UNIX timestamp
· %ai: author date, ISO 8601-like format
· %aI: author date, strict ISO 8601 format
· %cn: committer name
· %cN: committer name (respecting .mailmap, see git-shortlog(1) or git-blame(1))
· %ce: committer email
· %cE: committer email (respecting .mailmap, see git-shortlog(1) or git-blame(1))
· %cd: committer date (format respects --date= option)
· %cD: committer date, RFC2822 style
· %cr: committer date, relative
· %ct: committer date, UNIX timestamp
· %ci: committer date, ISO 8601-like format
· %cI: committer date, strict ISO 8601 format
· %d: ref names, like the --decorate option of git-log(1)
· %D: ref names without the " (", ")" wrapping.
· %e: encoding
· %s: subject
· %f: sanitized subject line, suitable for a filename
· %b: body
· %B: raw body (unwrapped subject and body)
· %N: commit notes
· %GG: raw verification message from GPG for a signed commit
· %G?: show "G" for a good (valid) signature, "B" for a bad signature, "U" for a good signature with unknown validity, "X" for a good signature that has expired, "Y" for a good
signature made by an expired key, "R" for a good signature made by a revoked key, "E" if the signature cannot be checked (e.g. missing key) and "N" for no signature
· %GS: show the name of the signer for a signed commit
· %GK: show the key used to sign a signed commit
· %gD: reflog selector, e.g., refs/stash@{
1} or refs/stash@{
2 minutes ago}; the format follows the rules described for the -g option. The portion before the @ is the refname as given on
the command line (so git log -g refs/heads/master would yield refs/heads/master@{
0}).
· %gd: shortened reflog selector; same as %gD, but the refname portion is shortened for human readability (so refs/heads/master becomes just master).
· %gn: reflog identity name
· %gN: reflog identity name (respecting .mailmap, see git-shortlog(1) or git-blame(1))
· %ge: reflog identity email
· %gE: reflog identity email (respecting .mailmap, see git-shortlog(1) or git-blame(1))
· %gs: reflog subject
· %Cred: switch color to red
· %Cgreen: switch color to green
· %Cblue: switch color to blue
· %Creset: reset color
· %C(...): color specification, as described under Values in the "CONFIGURATION FILE" section of git-config(1). By default, colors are shown only when enabled for log output (by
color.diff, color.ui, or --color, and respecting the auto settings of the former if we are going to a terminal). %C(auto,...) is accepted as a historical synonym for the default
(e.g., %C(auto,red)). Specifying %C(always,...) will show the colors even when color is not otherwise enabled (though consider just using `--color=always to enable color for the whole
output, including this format and anything else git might color). auto alone (i.e. %C(auto)) will turn on auto coloring on the next placeholders until the color is switched again.
· %m: left (<), right (>) or boundary (-) mark
· %n: newline
· %%: a raw %
· %x00: print a byte from a hex code
· %w([<w>[,<i1>[,<i2>]]]): switch line wrapping, like the -w option of git-shortlog(1).
· %<(<N>[,trunc|ltrunc|mtrunc]): make the next placeholder take at least N columns, padding spaces on the right if necessary. Optionally truncate at the beginning (ltrunc), the middle
(mtrunc) or the end (trunc) if the output is longer than N columns. Note that truncating only works correctly with N >= 2.
· %<|(<N>): make the next placeholder take at least until Nth columns, padding spaces on the right if necessary
· %>(<N>), %>|(<N>): similar to %<(<N>), %<|(<N>) respectively, but padding spaces on the left
· %>>(<N>), %>>|(<N>): similar to %>(<N>), %>|(<N>) respectively, except that if the next placeholder takes more spaces than given and there are spaces on its left, use those spaces
· %><(<N>), %><|(<N>): similar to %<(<N>), %<|(<N>) respectively, but padding both sides (i.e. the text is centered)
· %(trailers[:options]): display the trailers of the body as interpreted by git-interpret-trailers(1). The trailers string may be followed by a colon and zero or more comma-separated
options. If the only option is given, omit non-trailer lines from the trailer block. If the unfold option is given, behave as if interpret-trailer’s --unfold option was given. E.g.,
%(trailers:only,unfold) to do both.
3. Sortie de ligne unique
3.1 git log --oneline
Et git log --pretty=oneline
presque, c'est une ligne de sortie (commitID comment) pour chaque soumission, la différence est que git log --oneline
le commit id est une abréviation.
Lorsqu'il y a une ligne vide entre la première ligne de commentaires et la deuxième ligne de commentaires, seule la première ligne de commentaires sera affichée, comme la dernière soumission (80a228c3) dans la figure ci-dessous. , seule la première ligne de commentaires sera affichée.
3.2 git log --oneline <fichier>
Imprimer tous les enregistrements de validation d'un fichier en mode ligne unique.
4. Générez les statistiques du montant de la modification de chaque soumission
4.1 git log --stat
4.2 git log --stat <fichier>
Générez tous les enregistrements de validation et changez les statistiques d'un fichier.
5. Générez toutes les modifications validées
5.1 git log -p
Générer un enregistrement de chaque commit et de ses modifications
5.2 git log -p <fichier>
Sortez tous les enregistrements de validation et leurs modifications pour un fichier.
6. Afficher les modifications d'un certain commit [ git show --stat commitID ]
7. Afficher le contenu modifié d'un commit [ git show commitID ]
8. Spécifiez le format de date [ git log --date= ]
La commande est suivie des options suivantes :
options | exemple |
---|---|
défaut | 25 août 21:15:01 2022 +0200 |
iso8601 | 2022-08-25 21:15:01 +0200 |
local | ven. 26 août 03:15:01 2022 |
brut | 1661454901 +0200 |
relatif | il y a 2 mois |
rfc2822 | jeu. 25 août 2022 21:15:01 +0200 |
court | 2022-08-25 |
9. Filtrer et afficher selon une certaine condition
options | illustrer |
---|---|
-n | Afficher les n premiers commits |
–sauter=n | Ne pas afficher les n premiers commits |
--author="chaîne" | Filtrez les soumissions des auteurs qui correspondent à la chaîne, par exemple, si la chaîne est "Joel", alors les auteurs seront affichés comme "Joel abc", "Joel def", etc. |
--committer="chaîne" | Filtrer les commits des committers qui correspondent à la chaîne |
--since="date", --after="date" | Afficher les commits après un temps spécifié |
--until="date", --before="date" | Afficher les commits avant l'heure spécifiée |
--grep="chaîne" | Afficher les commits contenant la chaîne spécifiée dans leur description de commit |
-S "chaîne" | Afficher les commits avec des ajouts ou des suppressions correspondant à la chaîne spécifiée |
10. Générez l'enregistrement de validation pour chaque ligne du fichier
10.1 git reproche <fichier>
Sortir le dernier enregistrement de commit
10.2 git blame -L <numéro de ligne de début>,<numéro de ligne de fin> <fichier>
Sortir le dernier enregistrement de validation d'un fichier de numéro de ligne à numéro de ligne
git blame -L 5,5 <file> 代表第5行的提交记录
git blame <file> | tail -n <行数> 搭配tail命令还可以显示最后多少行的提交记录