Je recherche une solution, de tag Modifications des messages de validation.
pour moi une "tag" est quelque chose comme:
jusqu'à présent, j'utilise SVN, mais je veux passer à Git. S'il y aurait du standard, beaucoup d'outils comme Trac, Redmine, ... pourraient utiliser cela.
Je veux que cela réponde à des questions comme ceci:
arrière-plan:
jusqu'à présent, j'utilise l'unisson pour synchroniser entre Dev, Test et Prod System. Mais l'Unisson ne sait rien à propos de la gestion de la version (qui est SVN au moment des moments). Je veux passer à Git. Et je veux voir vite, quels sont les changements.
Exemple: je veux voir des changements entre test et prod. Je ne veux pas voir les modifications du code source, mais les messages de validation. Mais parfois, il y a jusqu'à 100 commits. Ici, je veux un filtre, exclure les changements sans importance.
3 Réponses :
J'aime utiliser les balises suivantes: Cette balise est toujours la première chose dans le message de validation puis suivie d'une brève description et / ou de la question-identifiant de la question. système de suivi, s'il existe. J'utilise ces étiquettes avec SVN et Git et les avons jusqu'ici très commodes. Pour répondre à votre édition:
C'est pourquoi j'aime ces étiquettes de validation. Il est immédiatement visible si le commit change le comportement ou non. Si votre système de base de données change régulièrement ou si ces changements ou très importants pour vous, vous pouvez introduire une balise pour cela. J'aime aussi combiner ces tags dans un message commettre, le cas échéant. E.G., "Configuration de la DOC TEST DE TEST FOO". avec une balise de DB supplémentaire pour la base de données, vous pouvez facilement suivre les modifications liées à la base de données.
+1 pour la bonne réponse. Mais si je dois avoir plus d'informations sur le changement à l'aide de sa balise? par exemple. J'ai besoin de plus sur un défaut (son journaliste, sa criticité, ses étapes de reproduction, etc.) résolues dans une étiquette de corrective.
Ensuite, vous pouvez simplement ajouter toutes ces informations après la balise, par exemple, "Correction du problème FOO signalé par John Doe; ..."
Désolé, je ne comprends pas ce que vous entendez par ce dernier commentaire.
Le <-href="http://docs.scipy.org/doc/numpy/dev/gitwash/development_workflow.html" Rel="nofollow NOREFERRER"> NOBPY Development Workflow énumère certaines abréviations standard.
Je préfère attribuer chaque jeu de modifications avec un problème dans mon problème de suivi. En utilisant des suiveurs de problèmes connus comme JIRA, il est possible de sélectionner le problème résolu dans un jeu de modifications. Après avoir sélectionné un problème, la description du problème est automatiquement placée dans le message du jeu de modifications. Ils peuvent être suivis à l'avenir et être signalé dans votre tracker d'émission.
J'ai mis à jour la question. Les tags devraient répondre à des questions telles que ceci: "Si je mettez à jour un système, quels changements sont visibles pour le client, ou est-ce juste une mise à jour de maintenance?"
Comment gérez-vous les engagements qui ne sont pas connectés à un problème? E.G., si vous ajoutez ou corrigez une documentation ou un refacteur quelque chose?
@guettli: Toutes ces informations sont conservées dans votre problème. De plus, d'autres informations telles que celui demandaient la modification, la version du code source que ce changement appliqué, la première version dans laquelle ces changements concernés, ... sont conservées sur les problèmes sur le suivi de la question.
@Mort: En tant que pratique SCM (Software Configuration Management), chaque modification du système doit être effectuée en fonction d'un problème.
@Hsalimi: Je suis en désaccord. Pensez à la situation suivante: vous travaillez dans votre code et trouvez des commentaires en ligne contenant des erreurs d'orthographe, mais ne sont liées à aucun problème dans votre base de données de problèmes. Que fais-tu? Créer un problème pour une erreur d'orthographe pour pouvoir connecter le commit à un problème? Je voudrais simplement commettre la correction de l'orthographe d'orthographe à l'aide d'un message commet comme "Doc Fix orthographe". De cette façon, lors de la numérisation de l'historique de validation, on voit immédiatement qu'on ne doit pas avoir de plus près ce commettre ce commettre.
la plupart du temps que j'utilise le système de balises de TYPO3: http: //wiki.typo3 .org / commitmessage_format_ (git)
Il utilise des balises dans les messages tels que ceci: TYPO3 Tags:
plus d'autres drapeaux peuvent être ajoutés dans certaines circonstances:
exemple de sujet descriptions de sujet:
[tag] message court
Bien sûr, j'ai toujours abordé un numéro de numéro pour le suivi des émissions. Nous utilisons Jira afin qu'il devienne quelque chose comme ceci: [tag] jira-123 message court