Des alternatives Git à «svn info» qui peuvent être incluses dans un build pour la traçabilité?

Je recherche une alternative à Git pour “svn info”.

Aujourd’hui, j’ai ajouté des informations que Subversion me fournit avec la commande “svn info” directement dans ma version, et celles-ci sont ensuite envoyées dans un fichier source qui les imprime au démarrage. De cette façon, je sais toujours d’où vient cette construction et comment la récupérer.

Si vous avez “svn info” comme l’URL, la racine du référentiel, l’UUID du référentiel et la révision, vous avez un bon lien entre ce qui est déployé et le système de compilation. Et si quelqu’un signale un bogue, vous savez d’où provient ce logiciel, et comme cette information a été automatiquement incluse, le risque d’erreur humaine est moindre.

Maintenant, la question est de savoir quelles informations dois-je obtenir de Git pour pouvoir identifier plus tard d’où vient cette version? Et comment utiliser ces informations pour revenir exactement à cette version?

(Peut-être que je dois append des informations sur le “build computer” aussi, puisque Git est dissortingbué.)


Mise à jour : Utiliser Rev-Parse était vraiment utile, et j’ai quelque chose comme ça:

cj@zap:~/git_test$ git rev-parse HEAD 72ce5f3e13c61f76fde5c58cefc85eed91b6f1f8 

Et avec ce nombre magique, il est possible de faire plus tard:

 cj@zap:~/git_test$ git checkout 72ce5f3e13c61f76fde5c58cefc85eed91b6f1f8 

Et je suis de retour où j’étais.


Mise à jour : Je pense que si je prends certaines parties des scripts fournis par VonC et que je les place dans mon fichier de compilation, j’obtiendrai le résultat recherché.


Mise à jour :

Une note sur “git describe”. Vous avez besoin d’un vrai tag (tag -a) plus tôt dans votre historique de twig pour que cela fonctionne ou vous obtiendrez quelque chose comme ça.

 fatal: cannot describe '72ce5f3e13c61f76fde5c58cefc85eed91b6f1f8' 

Le problème est également décrit dans Git Tag: la mauvaise chose par défaut .

Mais s’il vous plaît noter que la caisse semble fonctionner de toute façon, même si c’était un message d’erreur.

 git checkout 72ce5f3e13c61f76fde5c58cefc85eed91b6f1f8 

La chose normale semble cependant être que vous créez quelque chose comme une balise “ver1.0”, et si vous continuez à travailler, vous obtenez quelque chose comme ceci:

 cj@zap:~/git_test$ git describe ver1.0-2-g4c7a057 cj@zap:~/git_test$ git tag -a ver2.0 cj@zap:~/git_test$ git describe ver2.0 cj@zap:~/git_test$ git commit . -m "something..." Created commit ac38a9d: something... 1 files changed, 1 insertions(+), 0 deletions(-) cj@zap:~/git_test$ git describe ver2.0-1-gac38a9d 

Donc, lorsque vous utilisez des describe correctes, cela fonctionne et peut produire des résultats plus lisibles pour l’homme, et cela peut aussi être très utile.

Pour compléter la réponse de Charles, vous pouvez également créer un script affichant “sn info” comme des informations, comme celle-ci (déjà mentionnée ici ).

 #!/bin/bash # author: Duane Johnson # email: [email protected] # date: 2008 Jun 12 # license: MIT # # Based on discussion at http://kerneltrap.org/mailarchive/git/2007/11/12/406496 pushd . >/dev/null # Find base of git directory while [ ! -d .git ] && [ ! `pwd` = "/" ]; do cd ..; done # Show various information about this git directory if [ -d .git ]; then echo "== Remote URL: `git remote -v`" echo "== Remote Branches: " git branch -r echo echo "== Local Branches:" git branch echo echo "== Configuration (.git/config)" cat .git/config echo echo "== Most Recent Commit" git log --max-count=1 echo echo "Type 'git log' for more commits, or 'git show' for full commit details." else echo "Not a git repository." fi popd >/dev/null 

Ce qui produirait quelque chose comme:

 == Remote URL: origin [email protected]:canadaduane/my-project.git == Remote Branches: origin/work trunk trunk@1309 trunk@2570 trunk@8 == Local Branches: master * work == Configuration (.git/config) [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [svn-remote "svn"] url = svn+ssh://svn.my-project.com/srv/svn fetch = my-project/trunk:refs/remotes/trunk [remote "origin"] url = [email protected]:canadaduane/my-project.git fetch = refs/heads/*:refs/remotes/origin/* [github] user = canadaduane repo = my-project == Most Recent Commit commit b47dce8b4102faf1cedc8aa3554cb58d76e0cbc1 Author: Duane Johnson  Date: Wed Jun 11 17:00:33 2008 -0600 Added changes to database schema that will allow decentralization from content pointers table type 'git log' for more, or 'git show' for full commit details. 

Je sais que la réponse est déjà acceptée, mais cela peut aider quelqu’un qui recherche des informations distantes et de twig.

  git remote show origin 

Dans git, l’identifiant de validation est unique dans un projet, même dans le code dissortingbué. Vous pouvez également extraire un identifiant de validation, donc si vous voulez un identifiant vous permettant de revenir à l’état du code qui a généré une génération, vous avez juste besoin de l’identifiant de validation.

 git rev-parse HEAD 

Bien sûr, vous voulez probablement être sûr qu’il n’y a pas de modifications en attente dans l’arborescence ou l’index de travail, donc vous pouvez vérifier qu’il n’y a pas de sortie vers quelque chose comme ceci:

 git diff --name-status HEAD 

ou utilisez simplement le code de sortie de:

 git diff --quiet HEAD 

Les seules choses que vous voudrez peut-être enregistrer à propos de la machine de génération sont des facteurs environnementaux tels que les versions de chaîne d’outils et l’état dans lequel se trouvaient les outils ne provenant pas du référentiel.

Si vous disposez d’un référentiel maître central, vous pouvez enregistrer l’URL de ce fichier, même si l’identifiant de validation est unique pour tous les clones du projet, ce n’est pas une information critique pour identifier le commit.

Vous pouvez obtenir les informations distantes comme dans “svn info” en:

 git remote -v
 git describe 

est tout ce dont vous avez besoin Assurez-vous simplement d’avoir créé au moins une balise (appropriée).

Je ne sais pas si c’est ce que vous voulez, mais si vous voulez intégrer des informations de version au moment de la construction, étiquetez vos versions et observez comment Git lui-même le fait (le kernel Linux utilise le même mécanisme) en utilisant Makefile et script GIT-VERSION-GEN (les deux liens sont sur gitweb sur repo.or.cz) .

GIT-VERSION-GEN utilise à son tour git-describe .

Voici gitinfo.ps1 (ou Get-GitInfo.ps1 pour les puristes), une version PowerShell du script shell de Duane Johnson:

 # From http://stackoverflow.com/a/924657/990504 # Duane Johnson's script translated to PowerShell by Jonathan Fischer 2015.04.25 Push-Location . # Find base of git directory while ( $true ) { if ( Test-Path -PathType container .git ) { # Show various information about this git directory Write-Output "== Remote URL: $(git remote -v)" Write-Output "`n== Remote Branches: " git branch -r Write-Output "`n== Local Branches:" git branch Write-Output "`n== Configuration (.git/config)" Get-Content .git/config Write-Output "`n== Most Recent Commit" git log --max-count=1 Write-Output "Type 'git log' for more commits, or 'git show' for full commit details." break } # Try parent directory. Set-Location .. # Stop if at root of drive. if ( (Get-Location).Path -match "[AZ]:\\$" ) { Write-Error "Not a Git repository." break } } # Note: even though the popd was not ssortingctly necessary in the bash version # unless the script was sourced/dotted, PowerShell has the questionable behavior # where scripts modify the current directory (and environment!) of the calling # process. So we need the Pop-Location. Pop-Location