Je viens de passer de subversion en git. L'architecture centralisée de Subversion lui confère un numéro de révision significatif que j'ai utilisé dans le journal de modification de notre application Web pour faciliter la connexion et voir la version exécutée sur n'importe quel serveur donné. Git n'a pas de numéro de construction amical. Au lieu de cela, j'ai vu qu'il a suggéré d'analyser quelque chose à partir de la sortie de Je ne suis pas convaincu que nous utiliserons toujours des noms conviviaux pour nos succursales (parfois, nous les nommons pour un client individuel qui ne veut pas le fait qu'ils utilisent notre système publié). Je pense donc que je pouvais avoir la construction générer une balise Datestamp / horodatage comme Nous déployons actuellement pour tester tous les quelques jours, l'intégration quelques fois par mois (en rafales) et la production tous les deux mois. Statut GIT ou GIT Tags .
2012-11-21_08-40-23 et utilisez-le de la manière dont j'ai l'habitude d'utiliser le numéro de révision Subversion. La construction ne générerait que cette balise et l'ajoutait à GIT lorsque nous construisons un fichier de guerre pour le déploiement, de sorte que tout déploiement sur n'importe quel serveur générerait une étiquette.
4 Réponses :
Vous voudrez peut-être regarder Script Git-Version-Gen pour générer de belles numéros de version.
Il suppose que vous avez des tags de formulaire 'vx.y' et vous donnera des numéros de version comme 'VX.Y-Z-AAAAAAAA' où Z est le nombre de commits depuis que Tag VX.Y et AAAAAAAA est raccourci SHA de la tête actuelle.
Quant à la stratégie de marquage, il vaut vraiment la peine de marquer des versions de libération de cette manière. L'utilisation de la version d'intégration et de test dépend de la manière dont le développement rapide est en mouvement.
Il fonctionnera également sur le développeur privé construit car les balises sont tirées du serveur d'origine de formulaire.
Au lieu de cela, j'ai vu qu'il a suggéré d'analyser quelque chose à partir de la sortie du statut GIT ou des étiquettes GIT.
C'était des suggestions laids. Vraiment laid et boiteux. Git décrit règle ici plus ou moins, lisant L'homme Git Décrivez sera beaucoup plus utile que
statut ououououTag oujournal ou 3-RD Scripts prêts à l'emploismth. Comme si cela, faites le truc d'une bonne nommaison de toute révision (et vous pouvez baliser uniquement
certains changements, pas tous les )
git décrit --tags - Long --Match 'Substring-of-Client_Tagfamily *'
Une fois des choses que vous trouverez lors de la passation de subversion en git, c'est que plusieurs concepts ont le même nom mais signifient des choses assez différentes.
Les branches font partie des plus grandes. La plupart des magasins que je connais à l'aide de GIT utilisent des succursales beaucoup . En fait, pour chaque caractéristique, correction de bugs, corvée, etc., il y a une branche. La branche est fondamentalement une construction temporaire tandis que le code est en cours de développement, examiné, testé localement. Ensuite, la succursale se fusionne dans le maître et qui est poussée à la ou dans la zone QA, puis finalement le maître est poussé à la production.
La nommée de la branche est l'une de ces choses de style. Un collègue j'ai utilisé INITS_PT575757_WHATEVER afin qu'il puisse référence à l'ID du système de suivi, l'autre collègue utilise Pete_1, car il traite, c'est juste une chose temporaire pour lui-même, à la fusion bientôt supprimée.
J'ai tendance à voir des balises plus utilisées pour les versions majeures mais YMMV
Plus d'informations sur le processus global à https://stackoverflow.com/a/9204499/631619
Le point du numéro de révision dans SVN devait pouvoir associer le code publié avec une révision spécifique du contrôle de la source. Je pense maintenant que ce marquage est inutile et que la réponse à ma question est en fait de simplement utiliser le hasch comme généré par: Je n'ai jamais répondu à ma propre question auparavant. Merci à tous pour vos réponses. J'ai donné à chacun de vous un +1 pour essayer. Je m'excuse si ma question était mal formulée (rétrospective - c'était). Si quelqu'un veut m'expliquer pourquoi c'est faux et comment le réparer (ou le faire mieux), j'accepterai volontiers leur réponse comme le correct.
Vous devez accepter votre propre réponse comme réponse correcte.
Un balise pointe vers un commit et est un "instantané" de l'état de votre codebase à un moment donné. Vous avez raison que l'on puisse se passer sans eux, mais la plupart les utilisent pour suivre les "versions" qui ont été publiées et pour le déploiement de l'application, il est recommandé de déployer des balises de balises VS car une balise est idempotente.