Créer un séquençage lors de l'utilisation du contrôle de version distribué

Question

Maintenant, nous sommes à l'aide de Perforce pour le contrôle de version. Il a la fonction pratique est strictement croissante numéro de changement que l'on peut utiliser pour se référer à s'appuie, par exemple, "vous aurez la correction si votre construction est au moins 44902".

J'aimerais passer de l'un à l'aide d'un système distribué (probablement git) pour le rendre plus facile à la branche et à travailler de la maison. (Les deux sont tout à fait possible avec Perforce, mais le workflow git a quelques avantages.) Ainsi, bien que "affluent développement" sera distribué et de ne pas se référer à une révision de séquençage, nous serions tout de même de maintenir un master git pensions que toutes les modifications devront alimenter avant de construire a été créé.

Quelle est la meilleure façon de préserver strictement croissante construire id? La façon la plus simple je pense est d'avoir une sorte de post-commit hook qui déclenche à chaque fois que le maître des pensions de mise à jour, et il les registres (le hash) de la nouvelle arborescence de l'objet (ou de l'objet commit? Je suis nouveau sur git) avec une base de données centralisée mains de l'ids. (Je dis "base de données", mais je le ferais probablement avec étiquettes git, et il suffit de regarder pour le prochain numéro de l'étiquette ou de quelque chose. Donc la "base de données" serait vraiment .git/refs/tags/build-id/.)

C'est réalisable, mais je me demandais si il n'y est plus facile, ou déjà mises en œuvre, ou de la norme/"meilleure pratique" la voie de l'accomplissement de cette.

Answer 1

Un nombre croissant monotone correspondant à la validation en cours peut être généré avec

 git log --pretty=oneline | wc -l
 

qui renvoie un seul numéro. Vous pouvez également ajouter sha1 actuel à ce nombre, pour ajouter un caractère unique.

Cette approche est meilleure que git describe , car elle ne nécessite pas l'ajout de balises et gère automatiquement les fusions.

Cela pourrait avoir des problèmes avec le rebasage, mais le rebasage est de toute façon une opération "dangereuse".

Answer 2

Je seconde la suggestion de l'utilisation de git describe. À condition que vous ayez une saine gestion des versions de la politique, et vous n'en fais pas des trucs dingues avec votre référentiel, git describe sera toujours monotone (au moins monotone que vous le pouvez, lors de votre révision de l'histoire est un DAG au lieu d'un arbre) et unique.

Une petite démonstration:

git init
git commit --allow-empty -m'Commit One.'
git tag -a -m'Tag One.' 1.2.3
git describe    # => 1.2.3
git commit --allow-empty -m'Commit Two.'
git describe    # => 1.2.3-1-gaac161d
git commit --allow-empty -m'Commit Three.'
git describe    # => 1.2.3-2-g462715d
git tag -a -m'Tag Two.' 2.0.0
git describe    # => 2.0.0

La sortie de l' git describe se compose des éléments suivants:

1. Le nouveau tag accessible à partir de la validation vous demandons de décrire
2. Le nombre de commits entre la livraison et le numéro de série (s'il est non nul)
3. La (nom abrégé) id de la livraison (si #2 est non nul)

#2 est ce qui rend la sortie monotone, #3 est ce qui le rend unique. #2 et #3 sont omis, lors de la validation est la balise, rendant git describe adapté également pour la production de rejets.

Answer 3

     git rev-list BRANCHNAME --count
 

c'est beaucoup moins de ressources que

     git log --pretty=oneline | wc -l
 

Answer 4

git tag peut suffire pour ce dont vous avez besoin. Choisissez un format d'étiquette que tout le monde acceptera de ne pas utiliser autrement.

Remarque: lorsque vous balisez localement, un git push ne mettra pas à jour les balises sur le serveur. Utilisez git push --tags pour cela.

Answer 5

Vous devriez enquêter git describe. Il donne une unique chaîne de caractères qui décrit la situation actuelle de la branche (ou tout passé commettre id) en termes de la dernière annoté de la balise, le nombre de commits depuis cette balise et une présentation abrégée de commettre l'id de la tête de la branche.

Je suppose que vous avez une seule branche que vous effectuez contrôlé versions de génération off. Dans ce cas, je balise un début de s'engager avec un format de tag et ensuite utiliser git décrire avec l'option --match pour décrire l'actuel CHEF relative à l'connu tag. Vous pouvez alors utiliser le résultat de git décrire comme est, ou si vous voulez vraiment un numéro unique, vous pouvez utiliser une expression régulière pour hacher le numéro de la balise.

En supposant que vous n'avez jamais reculer dans la direction de la le nombre de la suite s'engage toujours identifier un point unique dans la branche de l'histoire.

par exemple (en utilisant bash ou similaire)

# make an annotated tag to an early build in the repository:
git tag -a build-origin "$some_old_commitid"

# describe the current HEAD against this tag and pull out a build number
expr "$(git describe --match build-origin)" : 'build-origin-\([0-9]*\)-g'