Quel est le problème avec toutes les suggestions (sauf l' explication de Matthew Brett , à jour de ce message de réponse)?
Il suffit d'exécuter n'importe quelle commande fournie par d'autres sur l'historique jQuery Git lorsque vous êtes à un point différent de l'historique et de vérifier le résultat avec une représentation historique de l'étiquetage visuel (je l'ai fait, c'est pourquoi vous voyez ce post):
$ git log --graph --all --decorate --oneline --simplify-by-decoration
Aujourd'hui, de nombreux projets effectuent des versions (et donc du balisage) dans une branche distincte de la ligne principale .
Il y a une bonne raison à cela. Regardez simplement tous les projets JS / CSS bien établis. Pour les conventions utilisateur, ils portent des fichiers de version binaires / minifiés dans DVCS. Naturellement, en tant que responsable de projet, vous ne voulez pas gâcher votre historique de différences de ligne principale avec des objets binaires inutiles et effectuer la validation des artefacts de génération en dehors de la ligne principale .
Parce que Git utilise DAG et non un historique linéaire - il est difficile de définir la métrique de distance afin que nous puissions dire - oh ce régime est le plus proche de mon HEAD
!
Je commence mon propre voyage en (regardez à l'intérieur, je n'ai pas copié d'images à l'épreuve de fantaisie dans ce long post):
Quelle est la balise la plus proche dans le passé en ce qui concerne la ramification dans Git?
Actuellement, j'ai 4 définitions raisonnables de la distance entre le tag et la révision avec une diminution de l'utilité:
- longueur du chemin le plus court à partir
HEAD
de la base de fusion avec étiquette
- date de fusion de la base entre
HEAD
et tag
- nombre de tours atteignables depuis HEAD mais pas accessibles depuis la balise
- date du tag quelle que soit la base de fusion
Je ne sais pas comment calculer la longueur du chemin le plus court .
Script qui trie les balises en fonction de la date de la base de fusion entre HEAD
et balise:
$ git tag \
| while read t; do \
b=`git merge-base HEAD $t`; \
echo `git log -n 1 $b --format=%ai` $t; \
done | sort
Il est utilisable sur la plupart des projets.
Script qui trie les balises en fonction du nombre de tours accessibles depuis HEAD mais pas accessible depuis la balise:
$ git tag \
| while read t; do echo `git rev-list --count $t..HEAD` $t; done \
| sort -n
Si l'historique de votre projet a des dates de validation étranges (en raison de rebases ou d'une autre réécriture de l'histoire ou d'un crétin oubliez de remplacer la batterie du BIOS ou d'autres magies que vous faites sur l'historique), utilisez le script ci-dessus.
Pour la dernière option ( date de balise indépendamment de la base de fusion ) pour obtenir la liste des balises triées par date, utilisez:
$ git log --tags --simplify-by-decoration --pretty="format:%ci %d" | sort -r
Pour obtenir la date de révision actuelle connue, utilisez:
$ git log --max-count=1
Notez qu'ils git describe --tags
ont une utilisation dans leurs propres cas, mais pas pour trouver la balise la plus proche attendue humaine dans l'historique du projet .
REMARQUE Vous pouvez utiliser les recettes ci-dessus sur n'importe quelle révision, remplacez-les simplement HEAD
par ce que vous voulez!