Quando inserisco un comando:

git tag -l

Ottengo tali risultati:

rc-0.9.0.0
rc-0.9.0.1
rc-0.9.0.10
rc-0.9.0.11
rc-0.9.0.12
rc-0.9.0.2
rc-0.9.0.3
rc-0.9.0.4
rc-0.9.0.5
rc-0.9.0.6
rc-0.9.0.7
rc-0.9.0.8
rc-0.9.0.9

Invece di questo voglio:

rc-0.9.0.0
rc-0.9.0.1
rc-0.9.0.2
rc-0.9.0.3
rc-0.9.0.4
rc-0.9.0.5
rc-0.9.0.6
rc-0.9.0.7
rc-0.9.0.8
rc-0.9.0.9
rc-0.9.0.10
rc-0.9.0.11
rc-0.9.0.12

Come è possibile ordinare l'elenco corrente per ottenere tali risultati?

Usa l'ordinamento della versione

git tag -l | sort -V

o per la versione git> = 2.0

git tag -l --sort=v:refname
git tag -l --sort=-v:refname # reverse

Con Git 2.0 (giugno 2014), sarai in grado di specificare un ordinamento!

Vedere commit b6de0c6 , da commit 9ef176b , creato da Nguyễn Thái Ngọc Duy ( pclouds) :

 --sort=<type>

Ordina in un ordine specifico .
Il tipo supportato è:

• " refname" (ordine lessicografico),
• " version:refname" o " v:refname" (i nomi dei tag sono trattati come versioni).

Anteponi " -" per invertire l'ordinamento.

Quindi, se hai:

git tag foo1.3 &&
git tag foo1.6 &&
git tag foo1.10

Ecco cosa otterrai:

# lexical sort
git tag -l --sort=refname "foo*"
foo1.10
foo1.3
foo1.6

# version sort
git tag -l --sort=version:refname "foo*"
foo1.3
foo1.6
foo1.10

# reverse version sort
git tag -l --sort=-version:refname "foo*"
foo1.10
foo1.6
foo1.3

# reverse lexical sort
git tag -l --sort=-refname "foo*"
foo1.6
foo1.3
foo1.10

Dal momento che il commit b150794 (di Jacob Keller, git 2.1.0, agosto 2014), puoi specificare quell'ordine predefinito:

tag.sort

Questa variabile controlla l'ordinamento dei tag quando visualizzati da git-tag.
Senza l' --sort=<value>opzione " " fornita, il valore di questa variabile verrà utilizzato come predefinito.

commenti robinst :

l'ordinamento della versione può ora (Git 2.1+) essere configurato come predefinito:

git config --global tag.sort version:refname

Come notato da Leo Galleguillos nei commenti :

Per configurare Git in modo che mostri prima i tag più recenti ( ordine discendente ), aggiungi semplicemente un trattino prima della versione .
Il comando diventa:

git config --global tag.sort -version:refname

Con Git 2.4 (Q2 2015) , la versionsort.prereleasevariabile di configurazione può essere utilizzata per specificare quella v1.0-pre1precedentev1.0 .

Vedere commit f57610a di Junio ​​C Hamano ( gitster) .

^{Nota (vedi sotto) versionsort.prereleaseSuffixè ora (2017) un alias deprecato per versionsort.suffix.}

git 2.7.1 (febbraio 2016) migliorerà l'output di git tagse stesso.

Vedere commit 0571979 (26 gennaio 2016) e commit 1d094db (24 gennaio 2016) di Jeff King ( peff) .
^{(Fuso da Junio ​​C Hamano - gitster- in commit 8bad3de , 1 febbraio 2016)}

tag: non mostrare nomi di tag ambigui come " tags/foo"

Da quando b7cc53e ( tag.c: use ' ref-filter' API, 2015-07-11), git tagha iniziato a mostrare tag con nomi ambigui (cioè, quando esistono sia " heads/foo" che " tags/foo") come " tags/foo" invece che solo " foo".
Questo è entrambi:

• inutile; l'output di " git tag" include solo refs/tags, quindi sappiamo che " foo" significa quello in " refs/tags".
• e ambiguo; nell'output originale, sappiamo che la riga " foo" significa che " refs/tags/foo" esiste. Nel nuovo output, non è chiaro se intendiamo " refs/tags/foo" o " refs/tags/tags/foo".

Il motivo per cui ciò accade è che il commit b7cc53e è passato git taga utilizzare la %(refname:short)formattazione di output " " di ref-filter , che è stata adattata da for-each-ref. Questo codice più generale non sa che ci preoccupiamo solo dei tag e utilizza shorten_unambiguous_refper ottenere il file short-name.
Dobbiamo dirgli che ci interessa solo di " refs/tags/", e dovrebbe accorciarsi rispetto a quel valore.

aggiungiamo un nuovo modificatore al linguaggio di formattazione, " strip", per rimuovere un insieme specifico di componenti di prefisso.
Questo risolve " git tag" e consente agli utenti di richiamare lo stesso comportamento dai propri formati personalizzati (per " tag" o " for-each-ref") lasciando " :short" con lo stesso significato coerente in tutti i posti.

Se strip=<N>è allegato, strisce <N>slash-separate componenti del percorso dalla parte anteriore del refname (ad esempio, %(refname:strip=2)si trasforma refs/tags/fooin foo.
<N>Deve essere un numero intero positivo.
Se un arbitro visualizzato ha meno componenti rispetto <N>, le Interruzione di comando con un errore.

Per git tag, se non specificato, il valore predefinito è %(refname:strip=2).

Aggiorna Git 2.12 (Q1 2017)

Vedere commit c026557 , commit b178464 , commit 51acfa9 , commit b823166 , commit 109064a , commit 0c1b487 , commit 9ffda48 , commit eba286e (08 dic 2016) di SZEDER Gábor ( szeder) .
^{(Fuso da Junio ​​C Hamano - gitster- nel commit 1ac244d , 23 gennaio 2017)}

versionsort.prereleaseSuffixè un alias deprecato per versionsort.suffix.

La prereleaseSuffixfunzione di confronto delle versioni utilizzata in " git tag -l" non funzionava correttamente quando erano presenti due o più prerelease per la stessa versione (ad esempio 2.0, quando 2.0-beta1, e 2.0-beta2 sono presenti e il codice deve essere confrontato 2.0-beta1e 2.0-beta2).

Secondo questa risposta , su piattaforme che non supportano sort -Vcome Windows e OSX, puoi usare

git tag -l | sort -n -t. -k1,1 -k2,2 -k3,3 -k4,4

Combinando le risposte già qui:

Repository locale

git -c 'versionsort.suffix=-' tag --list --sort=-v:refname

• suffix=-impedirà di 2.0-rcvenire "dopo"2.0
• --sort=- metterà il numero di versione più alto in alto.

Repository remoto

git -c 'versionsort.suffix=-' ls-remote -t --exit-code --refs --sort=-v:refname "$repo_url" \
    | sed -E 's/^[[:xdigit:]]+[[:space:]]+refs\/tags\/(.+)/\1/g'

Il vantaggio di ciò è che nessun oggetto viene scaricato dal telecomando.

Per maggiori informazioni vedi questa risposta .

Per ottenere uno smistamento inverso con l' sort -Vapproccio:

git tag -l | sort -V --reverse

Adatta questo script perl , che ordina i tag che assomigliano client_release/7.2/7.2.25, al tuo schema di tagging specifico.

Ho finito per scrivere un semplice script di shell per semplificare questo compito.

#!/usr/bin/env bash

TAGS=$(git tag)
CODE=$?

if [ $CODE = 0 ]; then
    echo "$TAGS" | sort -V
fi

exit $CODE

L'ho salvato come git-tags nel mio $PATHed eseguito git tagsogni volta che ho bisogno di elencare i tag.