Comment obtenir le nombre de validations Git?


753

J'aimerais obtenir le nombre de validations de mon référentiel Git, un peu comme les numéros de révision SVN.

L'objectif est de l'utiliser comme un numéro de build incrémentiel unique.

Je fais actuellement comme ça, sur Unix / Cygwin / msysGit:

git log --pretty=format:'' | wc -l

Mais je pense que c'est un peu un hack.

Y a-t-il une meilleure façon de le faire? Ce serait cool si je n'avais pas vraiment besoin wcou même Git, donc cela pourrait fonctionner sur un Windows nu. Il suffit de lire un fichier ou une structure de répertoire ...


1
Vous pouvez trouver des réponses intéressantes ici: quel est l'équivalent git pour le numéro de révision?
Sebastien Varrette

190
git rev-list HEAD --count git rev-list
Jake Berger

14
@jberger: Je pense que votre commentaire devrait être converti en réponse.
utapyngo

@utapyngo: étant donné les 13 autres réponses, je savais que ce serait enterré. Je l'ai ensuite posté ici .
Jake Berger

@jberger, cette réponse ne fonctionne pas pour git1.7.0.
Vorac à 8h14

Réponses:


1160

Pour obtenir un commettras chef d' accusation pour une révision ( HEAD, master, un hachage commettras):

git rev-list --count <revision>

Pour obtenir le nombre de validations dans toutes les branches:

git rev-list --all --count

Je recommande de ne pas utiliser cela pour l'identificateur de build, mais si vous le devez, il est probablement préférable d'utiliser le nombre pour la branche contre laquelle vous construisez. De cette façon, la même révision aura toujours le même numéro. Si vous utilisez le nombre pour toutes les succursales, l'activité sur d'autres succursales pourrait changer le nombre.


27
git shortlog | grep -E '^[ ]+\w+' | wc -lsi vous voulez obtenir le nombre total et git shortlog | grep -E '^[^ ]'si vous voulez obtenir le nombre de commits pour chaque contributeur.
skalee

2
Merci d'avoir souligné wc -l. Minimalisme FTW. Je l'ai intégré à ma réponse.
Benjamin Atkin,

17
Cette solution est à la fois hacky (similaire à l' git log --pretty=format:'' | wc -lapproche donnée dans la question d'origine) et incorrecte: vous pouvez le voir en inversant la correspondance ( git shortlog | grep -Ev '^[ ]+\w+') et en voyant par exemple que les validations sans message (c'est-à-dire "<aucun>") ne sont pas comptées. L'utilisation git rev-list HEAD --countest à la fois plus succincte et plus précise.
ctrueden

17
@BenAtkin: Mes excuses; je n'avais pas l'intention d'être offensant, mais simplement factuel. Point pris sur la date de la réponse. À l'époque, votre solution était peut-être la meilleure disponible. Mais je maintiens ma déclaration selon laquelle git rev-list HEAD --countc'est une meilleure solution maintenant.
ctrueden

3
Ajouté également une réponse et fonctionne également avec les anciennes versions:git log --oneline | wc -l
Jimmy Kane

155

git shortlog est une façon.


5
Ty. Cela a fonctionné pour moi lors du comptage des commits dans une plage; git shortlog sha1..sha2
RJFalconer

1
Oui, la première ligne de git shortlog contient le nombre de validations. Problème résolu.
Robert Massaioli

5
Le nombre de validations est regroupé par committer, pas si bon. Peut compter les lignes dans git shortlog, mais cela ne fonctionne pas sur ssh sans terminal pour une raison quelconque (pager?). La solution originale du demandeur est la meilleure! git log --pretty = format: '' | wc -l
Sam Watkins

4
Cependant, je suggérerais git rev-list HEAD --countplutôt que l'approche originale donnée dans le PO. Dans mes tests, il git log --pretty=format:'' | wc -lest décalé d'un.
ctrueden

3
@ctrueden git log --oneline | wc -ln'est pas en reste (OS X 10.8.5).
Andy Stewart

111

git rev-list HEAD --count

git rev-list

git rev-list <commit>: Liste les validations accessibles en suivant les liens parents du commit donné (dans ce cas, HEAD ).

--count : Affiche un nombre indiquant le nombre de validations qui auraient été répertoriées et supprime toutes les autres sorties.


101

Cette commande renvoie le nombre de validations regroupées par committers:

git shortlog -s

Production:

14 John lennon
9  Janis Joplin

Vous voudrez peut-être savoir que l' -sargument est la forme de contraction de --summary.


11
git shortlogen soi ne répond pas à la question initiale du nombre total de commits (non groupés par auteur). Utilisez git rev-list HEAD --countplutôt.
ctrueden

5
Impressionnant! Vous pouvez trier par | sort -ntrop
Mohsen

54

Si vous cherchez un identifiant unique et encore tout à fait lisible pour les commits, git describe pourrait être exactement ce qu'il vous faut.


2
Cela pourrait fonctionner et serait plus facile à utiliser qu'un algo sur mesure. +1
VonC

2
Je ne savais pas que Git décrivait. Ce petit nombre entre le nom du tag et le sha1 est exactement ce que je cherchais. Je vous remercie.
Splo

2
Jetez un œil au script GIT-VERSION-GEN et à la façon dont il est utilisé dans le référentiel git, et à un script similaire dans les sources du noyau Linux (et comment ils sont utilisés dans Makefile).
Jakub Narębski

Cela donne un identifiant unique, mais pas INCRÉMENTAL. Ça ne marche pas pour moi. Cependant, la réponse de Ben Atkin propose le nombre de validations, qui en pratique devrait être incrémentiel. La réponse d'Aaron Digulla est plus sûre, mais nécessite également plus de travail.
JOM

2
Oui, c'est parce que le concept d'un ID incrémentiel n'a aucun sens avec les systèmes de contrôle de version distribués.
Bombe

34

Vous n'êtes pas le premier à penser à un "numéro de révision" dans Git , mais 'wc " est assez dangereux, car la validation peut être effacée ou écrasée, et l'historique revisité.

Le "numéro de révision" était particulièrement important pour Subversion car il était nécessaire en cas de fusion (SVN1.5 et 1.6 se sont améliorés sur ce front).

Vous pourriez vous retrouver avec un hook de pré-validation qui inclurait un numéro de révision dans le commentaire, avec un algorithme n'impliquant pas de rechercher tout l' historique d'une branche pour déterminer le numéro correct.

Bazaar est en fait venu avec un tel algorithme , et il peut être un bon point de départ pour ce que vous voulez faire.

(Comme le souligne la réponse de Bombe , Git a en fait un algorithme qui lui est propre, basé sur la dernière balise, plus le nombre de validations, plus un peu d'une clé SHA-1). Vous devriez voir (et voter) sa réponse si cela fonctionne pour vous.


Pour illustrer l'idée d'Aaron , vous pouvez également ajouter le hachage de validation Git dans le fichier "info" d'une application que vous distribuez avec votre application.

De cette façon, la boîte about ressemblerait à:

À propos de la boîte

Le numéro d'application fait partie de la validation, mais le «fichier« info »de l'application» est généré pendant le processus d'empaquetage, liant efficacement un numéro de version d' application à un ID de révision technique .


2
J'ai mis à jour mon script pour fonctionner avec Xcode 3. Vous pouvez vous procurer une version à jour sur gist.github.com/208825 .
Abizern

34

Vous pouvez simplement utiliser:

git shortlog -s -n

Résultat :

 827  user one
    15  user two
     2  Gest 

22

Un moyen simple est:

 git log --oneline | wc -l

oneline s'assure que.


1
'wc' n'est pas reconnu comme une commande interne ou externe, un programme exploitable ou un fichier de commandes.
user815693

Eh bien, quel système utilisez-vous? Est-ce un UNIX? /
Jimmy Kane

1
Cela semble aussi plus rapide si vous avez des milliers de validations. Toutes les autres commandes prennent trop de temps.
Danny Coulombe

21

Pour l'intégrer dans une variable, le moyen le plus simple est:

export GIT_REV_COUNT=`git rev-list --all --count`

5
En effet, git rev-listc'est l'outil correct à utiliser, pas git logcomme les autres disent.
Nayuki

1
Pour compter le nombre de validations dans la lignée pour atteindre HEAD: git rev-list --first-parent | wc -l
200_success

Vous n'avez pas besoin il wc -lsuffit d' utiliser le --countcommutateur: git rev-list --all --count.
slm

Merci @slm, j'ai mis à jour la réponse. Cependant, je soupçonne que la réponse originale est plus ancienne que le --countcommutateur lui-même.
John Gietzen

@JohnGietzen - oh ouais je pensais que 8-), ajoutait juste ce détail pour aider.
slm

17

Git shortlog est un moyen d'obtenir les détails de la validation:

git shortlog -s -n

Cela donnera le nombre de validations suivies du nom de l'auteur. L'option -s supprime tous les messages de validation pour chaque validation effectuée par l'auteur. Supprimez la même option si vous souhaitez également voir les messages de validation. L'option -n est utilisée pour trier la liste entière. J'espère que cela t'aides.


2
git shortlogen soi ne répond pas à la question initiale du nombre total de commits (non groupés par auteur). Utilisez git rev-list HEAD --countplutôt.
ctrueden



4

Si vous n'utilisez qu'une seule branche, comme master, je pense que cela fonctionnerait très bien:

git rev-list --full-history --all | wc -l

Cela ne produira qu'un nombre. Vous pouvez l'aliaser à quelque chose comme

git revno

pour rendre les choses vraiment pratiques. Pour ce faire, modifiez votre .git/configfichier et ajoutez-le dans:

[alias]
    revno = "!git rev-list --full-history --all | wc -l"

Cela ne fonctionnera pas sous Windows. Je ne connais pas l'équivalent de "wc" pour ce système d'exploitation, mais écrire un script Python pour faire le décompte pour vous serait une solution multi-plateforme.

EDIT : Obtenez le décompte entre deux commits:


Je cherchais une réponse qui montrerait comment obtenir le nombre de commits entre deux révisions arbitraires et n'en ai pas vu.

git rev-list --count [older-commit]..[newer-commit]

3

Générez un nombre lors de la construction et écrivez-le dans un fichier. Chaque fois que vous faites une version, validez ce fichier avec le commentaire "Build 147" (ou quel que soit le numéro de build actuellement). Ne validez pas le fichier pendant le développement normal. De cette façon, vous pouvez facilement mapper entre les numéros de build et les versions dans Git.


Si deux développeurs distribués faisaient cela, leurs numéros de build n'entreraient-ils pas en collision / ne se croisaient-ils pas périodiquement? Que se passerait-il s'ils faisaient tous les deux une compilation entre les mêmes tours d'un référentiel partagé, ou peut-être qu'une collision ne se produirait que si l'un ou l'autre avait des modifications non validées dans le référentiel partagé. Pas certain.
plaques de cuisson

Bien sûr, mais le conflit vous dit quoi faire: parlez simplement à l'autre ou utilisez toujours un numéro plus élevé. Rappelez-vous: un nombre ne peut pas guérir comme par magie un processus de construction brisé. C'est juste un rappel ou un indice que vous devez vérifier quelque chose.
Aaron Digulla

1
Ahh, oui, le fichier magic buildno.txt est validé avec le reste. Bonne approche pour une petite équipe ou une grande équipe qui évite les constructions parallèles. Le seul endroit où je peux penser que cela pourrait ne pas fonctionner aussi bien est pour une grande équipe utilisant un langage de script (python) qui n'a pas besoin d'un processus de construction (pour affecter une seule personne à la construction).
plaques de cuisson

3

Dans notre entreprise, nous sommes passés de SVN à Git. Le manque de numéros de révision était un gros problème!

Faites git svn clone, puis marquez le dernier commit SVN par son numéro de révision SVN:

export hr=`git svn find-rev HEAD`
git tag "$hr" -f HEAD

Ensuite, vous pouvez obtenir le numéro de révision à l'aide de

git describe --tags --long

Cette commande donne quelque chose comme:

7603-3-g7f4610d

Signifie: La dernière balise est 7603 - c'est la révision SVN. 3 - est le nombre de commits. Nous devons les ajouter.

Ainsi, le numéro de révision peut être compté par ce script:

expr $(git describe --tags --long | cut -d '-' -f 1) + $(git describe --tags --long | cut -d '-' -f 2)

1

Celui que j'utilisais était:

git log | grep "^commit" | wc -l

Simple mais cela a fonctionné.


4
il faut une ligne de message de validation commençant par "commit" pour briser le décompte. Par exemple: "erreurs corrigées et tests brisés que j'ai accidentellement poussés lors du dernier \ ncommit"
Paweł Polewicz

1

En utilisant la syntaxe Bash,

$(git rev-list --count HEAD)

semble bien pour une histoire purement linéaire. Si vous voulez aussi parfois avoir des «numéros» de succursales (basés sur master), pensez à:

$(git rev-list --count $(git merge-base master HEAD)).$(git rev-list --count ^master HEAD)

Lorsque vous exécutez à partir d'une caisse master, vous obtenez simplement 1234.0ou similaire. Lorsque vous exécutez à partir d'une caisse d'une branche, vous obtiendrez quelque chose comme 1234.13, s'il y a eu 13 commits effectués sur cette branche. Évidemment, cela n'est utile que dans la mesure où vous basez au plus une branche sur une masterrévision donnée .

--first-parent pourrait être ajouté au micro-numéro pour supprimer certains commits résultant uniquement de la fusion d'autres branches, bien qu'il soit probablement inutile.


1

Tu peux essayer

git log --oneline | wc -l

ou pour lister tous les commits effectués par les personnes contribuant dans le référentiel

git shortlog -s

1

git config --global alias.count 'rev-list --all --count'

Si vous ajoutez ceci à votre configuration, vous pouvez simplement référencer la commande;

git count


0

Utilisez git shortlog comme ceci

git shortlog -sn

Ou créez un alias (pour un terminal basé sur ZSH)

# show contributors by commits alias gcall="git shortlog -sn"


0

Que diriez-vous de faire un alias?

alias gc="git rev-list --all --count"      #Or whatever name you wish
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.