Quel est l'équivalent Git du numéro de révision ?

Question

Nous utilisons SVN au travail, mais pour mes projets personnels, j'ai décidé d'utiliser Git. J'ai donc installé Git hier, et je me demande ce qu'est le numéro de révision équivalent dans Git .

Disons que nous travaillons sur la version 3.0.8 et que chaque correction de bug a son propre numéro de révision que nous pouvons utiliser lorsque nous parlons de cette correction de bug. Donc, si je marque le code dans Git à 3.0.8, que puis-je utiliser comme numéro de révision ou autre type d'identification plus détaillée ? Je trouve que le hachage n'est pas très convivial pour les humains.

Answer 1

Avec un Git moderne (1.8.3.4 dans mon cas) et sans utiliser de branches, vous pouvez le faire :

$ git rev-list --count HEAD
68

Answer 2

Bonne ou mauvaise nouvelle pour vous, ce dièse EST le numéro de révision. J'ai également eu des problèmes avec cela lorsque j'ai fait le passage de SVN à git.

Vous pouvez utiliser le "tagging" dans git pour marquer une certaine révision comme étant la "release" d'une version spécifique, ce qui permet de se référer facilement à cette révision. Regardez ceci article de blog .

La chose essentielle à comprendre est que git ne peut pas avoir de numéros de révision - pensez à la nature décentralisée. Si les utilisateurs A et B committent tous deux dans leurs dépôts locaux, comment git peut-il raisonnablement attribuer un numéro de révision séquentiel ? A n'a aucune connaissance de B avant qu'ils ne poussent/tirent les changements de l'autre.

Une autre chose à examiner est la simplification des branches pour les branches de correction de bogues :

Commencez par une version : 3.0.8. Puis, après cette version, faites ceci :

git branch bugfixes308

Cela créera une branche pour les corrections de bogues. Vérifiez la branche :

git checkout bugfixes308

Maintenant, faites tous les changements que vous voulez pour corriger les bogues.

git commit -a

Livrez-les, et revenez à la branche master :

git checkout master

Ensuite, tirez ces changements de l'autre branche :

git merge bugfixes308

De cette façon, vous disposez d'une branche de correction de bogues distincte pour chaque version, mais vous tirez toujours les modifications de correction de bogues dans votre tronc de développement principal.

Answer 3

El git describe crée un nom un peu plus lisible par l'homme qui fait référence à un commit spécifique. Par exemple, à partir de la documentation :

Avec quelque chose comme git.git current tree, j'obtiens :

[torvalds@g5 git]$ git describe parent
v1.0.4-14-g2414721

Par exemple, la tête actuelle de ma branche "parent" est basée sur la v1.0.4, mais comme elle a quelques commits en plus, describe a ajouté le nombre de commits supplémentaires ("14") et un nom d'objet abrégé pour le commit lui-même ("2414721") à la fin.

Tant que vous utilisez des balises judicieusement nommées pour marquer des versions particulières, on peut considérer que cela équivaut à peu près à un "numéro de révision" SVN.

Answer 4

Les autres posters ont raison, il n'y a pas de "revision-number".

Je pense que le meilleur moyen est d'utiliser les tags pour les "sorties" !

Mais j'ai utilisé les éléments suivants pour faux numéros de révision (juste pour que les clients puissent voir les révisions et la progression, car ils voulaient avoir les mêmes révisions croissantes de git que celles auxquelles ils étaient habitués par subversion).

Montrer la "révision actuelle" de "HEAD" est simulé en utilisant ceci :

git rev-list HEAD | wc -l

Mais que faire si le client me dit qu'il y a un bogue dans la "révision" 1302 ?

Pour cela, j'ai ajouté ce qui suit à la section [alias] de mon ~/.gitconfig :

show-rev-number = !sh -c 'git rev-list --reverse HEAD | nl | awk \"{ if(\\$1 == "$0") { print \\$2 }}\"'

en utilisant git show-rev-number 1302 imprimera alors le dièse pour la "révision" :)

J'ai fait un Blog Post (en allemand) sur cette "technique" il y a quelque temps.

Answer 5

Git n'a pas le même concept de numéros de révision que subversion. Au lieu de cela, chaque instantané fait avec un commit est marqué par une somme de contrôle SHA1. Pourquoi ? Il y a plusieurs problèmes avec un revno en cours dans un système de contrôle de version distribué :

Tout d'abord, le développement n'étant pas du tout linéaire, l'attachement d'un nombre est un problème plutôt difficile à résoudre de manière à satisfaire votre besoin en tant que programmeur. Essayer de résoudre ce problème en ajoutant un nombre peut rapidement devenir problématique lorsque le nombre ne se comporte pas comme vous l'attendez.

Deuxièmement, les numéros de révision peuvent être générés sur différentes machines. Cela rend la synchronisation des numéros beaucoup plus difficile - d'autant plus que la connectivité est unidirectionnelle ; vous n'avez peut-être même pas accès à toutes les machines qui possèdent le référentiel.

Troisièmement, dans git, un peu à l'initiative du système OpenCM, aujourd'hui disparu, la fonction identité d'un commit (ce que le commit est) est équivalent à son nom (l'identifiant SHA). Ce site dénomination = identité Le concept est très fort. Lorsque vous êtes assis avec un nom de commit en main, il identifie également le commit d'une manière infalsifiable. Cela vous permet de vérifier tous vos commits jusqu'au premier initial pour corruption avec le git fsck comando.

Maintenant, puisque nous avons un DAG (Directed Acyclic Graph) de révisions et que celles-ci constituent l'arbre actuel, nous avons besoin de quelques outils pour résoudre votre problème : comment distinguer les différentes versions. Tout d'abord, vous pouvez omettre une partie du hachage si un préfixe donné, 1516bd disons, identifie de façon unique votre engagement. Mais ceci est aussi plutôt artificiel. A la place, l'astuce est d'utiliser des tags et/ou des branches. Une étiquette ou une branche est une sorte de "note jaune" que vous attachez à un commit SHA1-id donné. Les tags sont, par essence, censés être immobiles alors qu'une branche se déplace lorsque de nouveaux commits sont effectués dans son HEAD. Il existe des moyens de faire référence à un commit autour d'un tag ou d'une branche, voir la page de manuel de git-rev-parse.

Habituellement, si vous avez besoin de travailler sur un morceau de code spécifique, ce morceau est en cours de changement et devrait en tant que telle être une branche avec un nom de sujet parlant. La création de nombreuses branches (20-30 par programmeur n'est pas rare, avec 4-5 branches publiées pour que d'autres puissent travailler dessus) est le secret d'un git efficace. Chaque morceau de travail devrait commencer comme une branche à part entière et être ensuite fusionné lorsqu'il est testé. Les branches non publiées peuvent être entièrement réécrites et cette partie de destruction de l'histoire est une force de git.

Lorsque le changement est accepté en master elle se fige quelque peu et devient de l'archéologie. À ce stade, vous pouvez l'étiqueter, mais le plus souvent une référence au commit particulier est faite dans un bug tracker ou un issue tracker via la somme sha1. Les balises sont généralement réservées aux changements de version et aux points de branchement des branches de maintenance (pour les anciennes versions).