Pousser les balises Git vers le référentiel distant
- Pousser les balises Git vers le référentiel distant
- Pousser toutes les balises Git
- Créer une balise Git
- Vérifiez votre balise Git nouvellement créée
- Conclusion
Si vous créez un git tag sur votre local, votre objectif doit être de partager vos modifications avec votre équipe pour un suivi facile.
le commit est l’une des actions populaires pour partager vos modifications. Mais une autre idée de partage et de suivi ajoutée à cela est Git Tag.
Cet article présentera comment pousser une balise Git créée vers un référentiel distant et les meilleures pratiques.
Pousser les balises Git vers le référentiel distant
Utilisez le code suivant pour transmettre une balise à votre référentiel distant.
git push <remote> <tagname>
Voici un exemple:
git push origin v1
Pousser toutes les balises Git
Utilisez le code suivant pour transférer toutes les balises vers votre référentiel distant.
git push <remote> --tags
Voici un exemple.
git push origin --tags
Avertissement : La suppression de balises peut être très difficile. Nous vous déconseillons donc d’utiliser ou de former des personnes pour pousser toutes les balises, y compris les balises incorrectes et non annotées !
À des fins d’équipe, des balises mal nommées peuvent prêter à confusion et peuvent rendre votre collaboration aussi perplexe que possible.
Créer une balise Git
Il existe deux types de balises git : annotées et légères.
Pour créer une balise git annotée, utilisez le code suivant.
git tag <tag_name> -a -m "Message"
Voici un exemple:
git tag v1 -a -m "Message"
Pour créer une balise git légère, utilisez le code suivant.
git tag <tag_name>
Voici un exemple.
git tag v1
Pour créer une balise git légère avec une description, utilisez le code suivant.
git tag <tag_name> -a
Voici un exemple:
git tag v1 -a
Vérifiez votre balise Git nouvellement créée
git show <tag-name>
La différence entre les balises annotées et légères est que le mot annoté lui-même indique qu’une balise est annotée avec le message, tandis que les balises légères ne conservent pas ces informations.
Conclusion
Conformément aux meilleures pratiques, par expérience, les développeurs se rendent compte que pousser toutes les balises immédiatement est une mauvaise pratique.
Référez-vous toujours à votre chef d’équipe pour savoir comment votre collaboration se déroule. Votre équipe utilise-t-elle des tags ? En avez-vous besoin pour suivre vos modifications ? Sur quels noms de balises ou règles de convention vos équipes ont-elles accepté de s’en tenir.
Il est recommandé, en particulier pour les gros projets, d’utiliser non seulement des messages de validation, mais également des balises.
Eh bien, pensez à ceci, supposons que vous ayez un projet construit à 70% en ce moment, et pensez à tous les changements que vous souhaitez revoir et revoir. Je suppose que vous utiliserez les journaux de validation et que vous verrez une liste complète de validations que vous et les membres de votre équipe allez être misérables à 50 %. Mais que se passe-t-il si vous avez des étiquettes dessus ? Alors c’est plutôt utile !