Compter le nombre de commits sur une branche Git


201

J'ai déjà trouvé cette réponse: nombre de commits sur la branche dans git mais cela suppose que la branche a été créée à partir de master.

Comment puis-je compter le nombre de commits le long d'une branche sans compter sur cette hypothèse?

Dans SVN, c'est trivial, mais pour une raison quelconque, c'est vraiment difficile à comprendre dans git.


Réponses:


381

Pour compter les validations de la branche sur laquelle vous vous trouvez:

git rev-list --count HEAD

pour une succursale

git rev-list --count <branch-name>

Si vous voulez compter les commits sur une branche qui sont effectués depuis que vous avez créé la branche

git rev-list --count HEAD ^<branch-name>

Cela comptera tous les commits jamais faits qui ne sont pas sur le nom de la branche.

Exemples

git checkout master
git checkout -b test
<We do 3 commits>
git rev-list --count HEAD ^master

Résultat: 3

Si votre succursale provient d'une succursale appelée develop:

git checkout develop
git checkout -b test
<We do 3 commits>
git rev-list --count HEAD ^develop

Résultat: 3

Ignorer les fusions

Si vous fusionnez une autre branche dans la branche actuelle sans avance rapide et que vous faites ce qui précède, la fusion est également comptabilisée. C'est parce que pour git, une fusion est un commit.

Si vous ne voulez pas compter ces commits, ajoutez --no-merges:

git rev-list --no-merges --count HEAD ^develop

7
aucun de ceux-ci n'affiche le bon nombre, par exemple master et branchname affichent le même nombre de commits.
botbot

Les commentaires n'autorisent pas vraiment le code, mais cela devrait montrer que cela fonctionne. ==== $ git init ==== $ touch test.txt ==== $ git add. ==== $ git commit -a ==== $ git rev-list --count HEAD => 1 ==== $ git rev-list --count master => 1 ==== $ git checkout -b test ==== $ git rev-list --count test => 1 ==== $ git rev-list --count HEAD ^ master => 0 ==== $ touch test2.txt ==== $ git ajouter . ==== $ git commit -a ==== $ git rev-list --count master => 1 ==== $ git rev-list --count test => 2 ==== $ git rev-list --count HEAD ^ master => 1 ====
Peter van der fait le

1
Je suis d'accord avec @botbot. Ce ne sont pas vraiment précis. Par exemple, essayez d'ajouter des validations de fusion ou des pull / rebase et notez que les décomptes décrits ci-dessus commencent à devenir peu fiables.
Deyon Samuel Washington

2
@wilmoore Vous voulez dire que vous obtenez un décompte supplémentaire après avoir fusionné une branche? C'est techniquement un commit, donc c'est compté. mais si vous ne voulez pas compter ces commits, ajoutez --no-merges. Je mettrai à jour la réponse.
Peter van der fait le

2
rev-list --count flag n'existe pas dans git 1.7. À l'heure actuelle, les suggestions contre-votées ci-dessous git logfonctionnent mieux que toutes les autres suggestions.
aaronbauman

61

Pour voir le nombre total de validations, vous pouvez faire comme Peter l'a suggéré ci-dessus

git rev-list --count HEAD

Et si vous voulez voir le nombre de commits effectués par chaque personne, essayez cette ligne

git shortlog -s -n

générera une sortie comme celle-ci

135  Tom Preston-Werner
15  Jack Danger Canty
10  Chris Van Pelt
7  Mark Reid
6  remi

3
quels sont ces nombres avant les noms? peux-tu expliquer ?
Ciasto piekarz

5
@Ciastopiekarz ce sont le nombre de commits par personne.
Asnad Atta

41

Cela peut nécessiter une version relativement récente de Git, mais cela fonctionne bien pour moi:

git rev-list --count develop..HEAD

Cela me donne un nombre exact de commits dans la branche actuelle ayant sa base sur master.

La commande dans la réponse de Peter git rev-list --count HEAD ^developinclut beaucoup plus de commits, 678 contre 97 sur mon projet actuel.

Mon historique de commit est linéaire sur cette branche, donc YMMV, mais il me donne la réponse exacte que je voulais, qui est "Combien de commits ai-je ajouté jusqu'à présent sur cette branche de fonctionnalité?".


Ça devrait être pareil. La documentation le dit . A special notation "<commit1>..<commit2>" can be used as a short-hand for "^'<commit1>' <commit2>". For example, either of the following may be used interchangeably: $ git rev-list origin..HEAD $ git rev-list HEAD ^origin
dosentmatter

Je suis confus: git fetch upstream; BEHIND=$(git rev-list --count HEAD..upstream/master); git merge --ff-only upstream/master~$BEHIND;ne fait pas la queue. BEHIND est comme 1800 alors qu'en réalité rien de plus que la fusion amont / maître ~ 400 ne produit des changements. l'utilisation --no-mergesn'est pas beaucoup mieux, donne comme 900. Et si je fais une fusion comme celle-ci avec ~ 800, et que le nombre de rev-list est de 1800, alors je fais une fusion avec ~ 790, j'obtiens entre 6 et 28 moins de rev -liste.
dlamblin le

8

Combien de commits a été effectué sur la branche actuelle depuis le début de l'historique, sans compter les commits des branches fusionnées:

git rev-list HEAD --count --first-parent

De la documentation git rev-list --help :

--first-parent

Suivez uniquement le premier commit parent lorsque vous voyez un commit de fusion. Cette option peut donner une meilleure vue d'ensemble lors de la visualisation de l'évolution d'une branche de sujet particulière, car les fusions dans une branche de sujet ont tendance à ne concerner que l'ajustement à la mise à jour en amont de temps en temps, et cette option vous permet d'ignorer les commits individuels apportés à votre histoire par une telle fusion. Ne peut pas être combiné avec --bisect.

Remarque: le clone peu profond réduira la taille de l'historique. Par exemple, si vous clonez avec --depth 1, retournera 1.

nombre de commits effectués depuis un autre commit:

git rev-list HEAD abc0923f --count --first-parent

ou le même:

git rev-list abc0923f.. --count --first-parent

ou utilisez toute autre référence git :

git rev-list master tag-v20 --count --first-parent

Nombre de commits effectués depuis l'année 2018

git rev-list HEAD --count --first-parent --since=2018-01-01

01-01-2018, 01.01.2018, 2018.01.01 fonctionne également.


git rev-label

J'ai écrit un script pour obtenir la révision de version de Git dans un format comme celui '$refname-c$count-g$short$_dirty'qui se développe en master-c137-gabd32ef.
L'aide est incluse dans le script lui-même.


git rev-list abc0923f .. --count --first-parent donne des résultats corrects pour ma branche mais la première commande donne une grande valeur
Jiss Raphel

5

Que diriez-vous git log --pretty=oneline | wc -l

Cela devrait compter tous les commits du point de vue de votre branche actuelle.


Quelle colonne comptez-vous? Est-ce le premier?
Hengjie

3

J'aime faire git shortlog -s -n --all. Vous donne une liste de style "classement" de noms et de nombre de commits.


2

Une façon de le faire est de répertorier le journal de votre succursale et de compter les lignes.

git log <branch_name> --oneline | wc -l

1

Eh bien, la réponse sélectionnée ne fonctionne pas si vous avez bifurqué votre branche hors d'une branche non spécifique (c'est-à-dire non masterou develop).

Ici, je propose une autre manière que j'utilise dans mes pre-pushhooks git.

# Run production build before push
echo "[INFO] run .git/hooks/pre-push"

echo "[INFO] Check if only one commit"

# file .git/hooks/pre-push
currentBranch=$(git symbolic-ref HEAD | sed -e 's,.*/\(.*\),\1,')

gitLog=$(git log --graph --abbrev-commit --decorate  --first-parent HEAD)

commitCountOfCurrentBranch=0
startCountCommit=""
baseBranch=""

while read -r line; do

    # if git log line started with something like "* commit aaface7 (origin/BRANCH_NAME)" or "commit ae4f131 (HEAD -> BRANCH_NAME)"
    # that means it's on our branch BRANCH_NAME

    matchedCommitSubstring="$( [[ $line =~ \*[[:space:]]commit[[:space:]].*\((.*)\) ]] && echo ${BASH_REMATCH[1]} )"

    if [[ ! -z ${matchedCommitSubstring} ]];then

      if [[  $line =~ $currentBranch ]];then
        startCountCommit="true"
      else
        startCountCommit=""

        if [[ -z ${baseBranch} ]];then
          baseBranch=$( [[ ${matchedCommitSubstring} =~ (.*)\, ]] && echo ${BASH_REMATCH[1]} || echo ${matchedCommitSubstring} )

        fi

      fi

    fi


    if [[ ! -z ${startCountCommit} && $line =~ ^\*[[:space:]]commit[[:space:]] ]];then
      ((commitCountOfCurrentBranch++))
    fi


done <<< "$gitLog"

if [[ -z ${baseBranch} ]];then

  baseBranch="origin/master"

else

  baseBranch=$( [[ ${baseBranch} =~ ^(.*)\, ]] && echo ${BASH_REMATCH[1]} || echo ${baseBranch} )

fi


echo "[INFO] Current commit count of the branch ${currentBranch}:  ${commitCountOfCurrentBranch}"

if [[ ${commitCountOfCurrentBranch} -gt 1 ]];then
  echo "[ERROR] Only a commit per branch is allowed. Try run 'git rebase -i ${baseBranch}'"
  exit 1
fi

Pour plus d'analyse, veuillez visiter mon blog


1

Comme l'OP fait référence au nombre de commits sur la branche dans git, je veux ajouter que les réponses données là-bas fonctionnent également avec n'importe quelle autre branche, au moins depuis la version 2.17.1 de git (et apparemment plus fiable que la réponse de Peter van der Does):

fonctionne correctement:

git checkout current-development-branch
git rev-list --no-merges --count master..
62
git checkout -b testbranch_2
git rev-list --no-merges --count current-development-branch..
0

La dernière commande donne zéro commits comme prévu puisque je viens de créer la branche. La commande précédente me donne le nombre réel de commits sur ma branche de développement moins le (s) merge-commit (s)

ne fonctionne pas correctement:

git checkout current-development-branch
git rev-list --no-merges --count HEAD
361
git checkout -b testbranch_1
git rev-list --no-merges --count HEAD
361

Dans les deux cas, j'obtiens le nombre de tous les commits dans la branche de développement et le maître dont les branches descendent (indirectement).


1

Si vous utilisez un système UNIX, vous pouvez faire

git log|grep "Author"|wc -l

0

Vous pouvez utiliser cette commande qui utilise awk sur git bash / unix pour obtenir le nombre de validations.

    git shortlog -s -n | awk '/Author/ { print $1 }'

-2

Vous pouvez également faire git log | grep commit | wc -l

et récupérez le résultat


2
Ce n'est pas fiable. Cela correspondrait aux commits qui ont "commit" dans le message de commit deux fois, par exemple.
rdb

@rdb Non, ce ne sera pas le cas. Il affichera uniquement le nombre de lignes contenant le mot «commit», donc une ligne ne sera jamais comptée deux fois.
iBug

@iBug: Vous manquez le point. Si le message de validation contient le mot «commit», il apparaît sur une ligne distincte de la ligne «commit a1b2c ...» dans la git logsortie, de sorte que le commit sera compté deux fois dans le résultat. Pire encore si le message de validation devait contenir le mot «commit» deux fois sur deux lignes distinctes.
rdb
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.