Deux choses se passent. Tout d'abord, les révisions git sont des révisions de l'arborescence complète de fichiers . En revanche, je crois que cvs et svn donnent des numéros de révision distincts aux fichiers individuels. Ainsi, dans cvs ou svn, l'opération "tag" disparaît et attache, par exemple, "stable-pre-new-spec" à file1 version 1.0.3, fichier 2 version 1.0.2, file3 version 2.0, fichier 4 version 1.3. 7, etc. Et quand vous voulez chercher en utilisant cette balise, le système va et trouve toutes les pièces avec cette balise. Dans git, la première révision concerne déjà l'ensemble, l'étiquetage ne fait que lui donner un autre nom.
Second-- et cela s'applique à de nombreux systèmes, y compris cm cvs et git svn-- donne le même nom à un état et la différence . Git appelle cette chose combinée un engagement. Donc vous posez des questions sur la version et cela vous montre un diff entre cela et l'état immédiatement précédent. Dans git, l'identifiant de validation est en fait une somme de contrôle de l'ensemble du contenu de l'arbre sauvegardé; c'est juste conventionnel de vous montrer le golden spike.
In git vous pouvez marquer un commit ou en créer une branche à tout moment après l'avoir créé.
Je ne vois pas le problème ici. 'stable-pre-new-spec' est un nom symbolique pour un commit donné. "git show" affichera le contenu de la balise (s'il s'agit d'une balise annotée), et au-dessous il affichera "git show ^{commit}" qui inclut le changeset de commit que vous avez tagué. –
Je ne veux pas marquer seulement mes commits. Je veux que l'instantané actuel de l'arbre source (c'est-à-dire chaque artefact) soit "étiqueté" avec une chaîne. –
La balise pointe vers l'arbre source à la validation donnée. C'est _is_ votre photo. Vous pouvez facilement utiliser "git checkout [-b] " pour revenir à la version et l'éditer davantage. Il n'y a pas de "marquage de tous les artefacts" dans git car cela n'a pas de sens: vous gérez toujours un référentiel complet, pas des fichiers uniques. –
Bombe