Branches et balises de version de Git Flow - avec ou sans préfixe «v»

119

J'ai vu plusieurs définitions contradictoires sur divers sites Web liés à git flow. Existe-t-il une recommandation officielle ou une seule source de vérité?

Succursales: release-1.2.3ourelease-v1.2.3

Tags: 1.2.3ouv1.2.3

git naming-conventions git-flow friederbluemle
la source
Voir aussi stackoverflow.com/questions/2006265/…
Raedwald

Réponses:

101

Eh bien, fondamentalement, c'est une question de préférence, mais je préfère la version avec le v, comme Semver le fait de cette façon et j'essaie de suivre cette spécification aussi étroitement que possible pour obtenir une version saine.

Cela facilite également le filtrage de ces balises, car vous pouvez appuyer sur v, puis sur la TABtouche pour l' auto-complétion: cela listera toutes les balises (et peut-être quelques branches), alors qu'il y a plusieurs chiffres avec lesquels une balise peut commencer.

Voir aussi: Existe - t-il une convention de dénomination standard pour les balises git?

TimWolla
la source
2
Merci, cela a du sens. Je pense qu'il est intéressant de voir que le projet Git Flow lui-même n'utilise pas les préfixes v: github.com/nvie/gitflow Pour les raisons que vous et @VonC avez postées, je préfère toujours les balises de version qui incluent le préfixe v.
friederbluemle
49
Semver a supprimé le préfixe v dans la version 2.
schmijos
1
Voir: github.com/mojombo/semver/blob/master/…
Leo
9
@schmijos @LeoTM - Le document indique uniquement que la v1.2.3 n'est pas une version sémantique. La question portait sur les balises Git. En fait, le dépôt semver utilise toujours v2.0.0comme balise pour la version 2: github.com/mojombo/semver/releases/tag/v2.0.0
friederbluemle
1
semver 2.0 semver.org ne dit rien sur les balises nécessaires pour commencer par un préfixe "v"!
jankal
30

Puisque v signifie version, les balises sont généralement nommées vX.YZ, avec XYZ suivant Semantic Versioning 2.0.0 .

Cela permet aux branches XYZ de coexister avec ces balises, sans avoir à traiter de message d'erreur comme "fatal: nom d'objet ambigu" (comme dans " Noms ambigus avec GIT? ").

Notez que les balises pour Git lui-même ont récemment été "adaptées" pour une raison surprenante: voir "Règles" de changement de version de code ".

VonC
la source
1
Lorsque les gens utilisent les meilleures pratiques comme semver , ils utilisent probablement un système comme Git Flow ou quelque chose de similaire. Cela éviterait ce conflit de refs (nom de la balise branche eq). En dehors de cela, qu'est-ce qui empêcherait alors de nommer une branche vX.Y.Z? Ce n'est pas vraiment un argument :)
kaiser
3
semver 2.0 semver.org ne dit rien sur les balises nécessaires pour commencer par un préfixe "v"!
jankal
@jankal Je suis d'accord. Je n'ai mentionné que semver pour la politique XYZ.
VonC
Un argument mineur est que plus de gens auront v1.2.3que b1.2.3:-)
Ciro Santilli 郝海东 冠状 病 六四 事件 法轮功
3

https://semver.org/#is-v123-a-semantic-version

La «v1.2.3» est-elle une version sémantique? Non, «v1.2.3» n'est pas une version sémantique. Cependant, le préfixe d'une version sémantique avec un «v» est une manière courante (en anglais) d'indiquer qu'il s'agit d'un numéro de version. L'abréviation de «version» en «v» est souvent vue avec le contrôle de version. Exemple: git tag v1.2.3 -m "Release version 1.2.3", auquel cas "v1.2.3" est un nom de tag et la version sémantique est "1.2.3".

Jetée
la source