Comment gérer le numéro de version dans Git?
Imaginons l'outil de ligne de commande blerp maintenu sur git . Cet outil a l'option (caché) --version Qui renvoie son version (disons 0.1.2) Et un autre --commit Qui retourne le numéro de commit à partir duquel il a été construit.
La version et le numéro de validation sont codés en dur sur la base de code.
Maintenant, je fais un correctif, puis je valide et reconstruis mon programme. Je verrai toujours 0.1.2 Bien que cette nouvelle version diffère de la 0.1.2 originale. Seul le commit me dira que ce n'est pas le même 0.1.2. Ce correctif vaut-il un numéro de version différent?
Une solution est que chaque fois que vous effectuez un commit, j'augmente le numéro de version codé en dur (ce qui implique de toujours modifier un minimum de 2 fichiers pour chaque commit). Il s'agit d'une solution contraignante qui ne fonctionne pas lorsque les développeurs travaillent sur différentes branches actives. Si Bob travaille sur la fonctionnalité foo de la version 0.1.2 Et qu'Alice fonctionne sur la fonctionnalité bar de la même version. Comment augmentent-ils leur numéro de version? Bob peut utiliser le impair et Alice le pair. Et si Eve travaille sur une troisième fonctionnalité?
Une autre solution peut être d'utiliser les balises Git pour générer automatiquement le numéro de version. Un script peut trouver la balise la plus proche commençant par v telle que v0.1.2 Et utiliser le nom de la balise comme numéro de version plus les n premiers chiffres du commit actuel (v0.1.2 (build 4acd21)) . Cela fonctionne bien si le répertoire de travail est propre. On peut imaginer ajouter un * Avant le numéro de build pour indiquer que le répertoire de travail n'est pas propre. Le principal problème avec cette solution est que si quelqu'un exporte les sources, il ne pourra pas construire blerp .
Quelle alternative possible peut résoudre ce problème?
Veuillez jeter un œil à la commande git describe . Cette commande vous montre la dernière balise et le nombre de validations effectuées après la définition de la balise. Il est également possible de montrer la saleté du référentiel.
Comme vous l'avez mentionné, cette commande ne fonctionnerait pas sans le référentiel git (dossier .git) et git installé. Mais c'est un développeur presque inimaginable aujourd'hui sans git mais avec tous les autres outils installés.
Alexey Kiselev et Dario ont déjà fait allusion à la réponse, mais je vais essayer de l'expliquer en détail.
Schémas de version
Il existe deux types de schémas de version:
- Numéro de version interne: il peut être incrémenté plusieurs fois par jour (par exemple, le numéro de contrôle de révision)
- Version publiée: cela change moins souvent (par exemple, le versionnage sémantique)
Les gens utilisent différents schémas selon leurs besoins, mais versioning sémantique est assez largement utilisé et rédigé par Tom Preston-Werner, cofondateur de GitHub.
Versioning sémantique
Le versioning sémantique suit le modèle de X.Y.Z
Ou plus lisible serait [major].[minor].[patch]-[build/beta/rc]
Par exemple. 1.2.0-beta
major or X peut être incrémenté en cas de modifications majeures du logiciel, comme une version d'API incompatible en amont.
minor or Y est incrémenté si des API rétrocompatibles sont introduites.
patch or Z est incrémenté après une correction de bogue.
Comment pouvons-nous y parvenir en utilisant Git?
En utilisant des balises:
Les balises dans Git peuvent être utilisées pour ajouter un numéro de version.
git tag -a "v1.5.0-beta" -m "version v1.5.0-beta"
ajoute une balise de version de v1.5.0-beta à votre référentiel Git actuel. Chaque nouveau commit après cela sera incrémenté automatiquement en ajoutant un numéro de commit et un hash de commit à cette balise. Il peut s'agir de vues à l'aide de git describe commande.
v1.5.0-beta-1-g0c4f33f ici -1- est le numéro de validation et 0c4f33f l'abréviation de hash de commit. Le préfixe g signifie "git".
Les détails complets peuvent être consultés en utilisant:
git show v1.0.5-beta
Comme vous le dites, les problèmes de version sont généralement résolus dans git en utilisant branch et tags (comme versioning sémantique motif).
La meilleure façon est d'utiliser git pour suivre uniquement les modifications dans la base de code, en ignorant (en utilisant .gitignore fichier) crée des fichiers et maintient un référentiel propre.
Les résultats des builds ( fichiers pré/compilés, fichiers exécutables, fichiers de distribution, zips, exe ...) peuvent dépendre des variables d'environnement (plateforme, système Arch, etc.) et doivent être séparés dans un enregistrement.
Si la base de code est très grande et difficile à maintenir, vous devriez peut-être envisager de la diviser en composants plus petits (ou git submodule ) pour éviter les dépendances croisées au moment du développement.
Les numéros de révision doivent être conservés par vous, pas par git. Comme contrairement à SVN, vous n'avez pas de numéro de révision incrémentiel croissant à chaque validation, il n'y a aucun moyen de sortir de la boîte pour git contextualiser ce qu'est votre version.