Marquage des messages de validation et des changesets

Question

Je recherche une solution pour marquer les changesets dans les messages de validation.

Pour moi, un "tag" est quelque chose comme:

Code
• nettoyer changement visible par l'utilisateur
• modifie la structure de base de données (ALTER TABLE)
• Documentation changement

Jusqu'à présent, j'utilise SVN, mais je veux passer à git. S'il y avait des standards, beaucoup d'outils comme trac, redmine, ... pourraient l'utiliser.

Je veux que cela répondre à des questions comme celle-ci:

• Si je mettre à jour un système, quels changements sont visibles pour le client, ou est juste une mise à jour maintance?
• Le schéma de base de données a-t-il changé entre deux versions?

Contexte:

Jusqu'à maintenant j'utiliser l'unisson pour synchroniser entre DEV, TEST et système PROD. Mais l'unisson ne sait rien de la gestion des versions (qui est SVN au momement). Je veux passer à git. Et je veux voir vite, quels sont les changements. Exemple: Je veux voir les 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, pour exclure les changements sans importance.

Answer 1

J'aime utiliser les balises suivantes:

ADD adding new feature 
FIX a bug 
DOC documentation only 
REF refactoring that doesn't include any changes in features 
FMT formatting only (spacing...) 
MAK repository related changes (e.g., changes in the ignore list) 
TEST related to test code only. 

Cette balise est toujours la première chose dans le message de commit puis suivi d'une brève description et/ou l'émission-id du système de suivi des problèmes, si cela existe J'utilise ces balises avec svn et git et jusqu'à présent, je les ai trouvées très pratiques.

Pour répondre à votre modification: C'est pourquoi j'aime ces balises 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 important pour vous, vous pouvez introduire une balise pour cela. J'aime aussi combiner ces balises dans un message de validation, le cas échéant. Par exemple, "TEST DOC setup of test foo".

Avec une balise DB supplémentaire pour la base de données, vous pouvez facilement suivre les modifications liées à la base de données.

Answer 2

Je préfère assigner chaque ensemble de modifications à un problème dans mon programme de suivi des problèmes. En utilisant des outils de suivi des problèmes connus comme jira, il est possible de sélectionner le problème résolu dans un ensemble de modifications. Après avoir sélectionné un problème, la description du problème est automatiquement placée dans le message de l'ensemble de modifications. Ils peuvent être suivis à l'avenir et également être signalés dans votre suivi des problèmes.

Answer 3

La plupart du temps, je suis en utilisant le système de balise de Typo3: http://wiki.typo3.org/CommitMessage_Format_(Git)

Il utilise des balises dans commits comme ceci: [TAG] Short message Bien sûr, je pop toujours un numéro d'émission pour le suivi de problème. Nous utilisons JIRA il deviendra quelque chose comme ceci: [TAG] JIRA-123 Short message

balises Typo3:

balises possibles sont:

• [REPORTAGE]: Une nouvelle fonctionnalité (également petits ajouts). Il s'agira probablement d'une fonctionnalité supplémentaire, mais elle pourrait également être supprimée. Cela ne peut se produire que dans la branche "master" de v4, car aucune nouvelle fonctionnalité n'est autorisée dans les branches plus anciennes. Les exceptions à cela doivent être discutées au cas par cas avec les responsables de publication correspondants.
• [CORRECTIF]: un correctif pour un bogue.
• [TÂCHE]: Tout ce qui n'est pas couvert par les catégories ci-dessus, par ex. nettoyage de style de codage. [API]: Une API a été modifiée, des méthodes ou des classes ont été ajoutées ou supprimées; les signatures de méthode ou les types de retour ont changé. Cela se réfère uniquement à l'API publique de TYPO3.

En outre d'autres drapeaux pourraient être ajoutés dans certaines circonstances:

• [!!!]: Briser le changement. Après ce correctif, quelque chose fonctionne différemment et l'utilisateur/administrateur/développeur de l'extension devra changer quelque chose. Cela ne devrait arriver que sur "maître".
• [WIP]: Travaux en cours. Ce drapeau sera supprimé une fois la version finale d'un changement disponible. Les modifications marquées WIP ne sont jamais fusionnées.
• [SECURITE]: Visualise qu'une modification corrige un problème de sécurité. Cette balise est utilisée par l'équipe de sécurité, au cas où vous trouveriez un problème de sécurité, veuillez toujours contacter l'équipe de sécurité!

descriptions de sujet Exemple:

• [BugFix] Throw HttpStatusExceptions dans tslib_fe
• [CORRECTIF] [Sécurité] Vulnérabilité d'Injection SQL dans les états préparés
• [DOSSIER] [CONF] Ajouter option de masquer Boîte de recherche BE dans la liste mod
• [!!!] [FONCTION] Déplacer l'édition de frontend avancée vers TER
• [!!!] [GROUPE] Retirer t3lib_sqlengine
• [!!!] [API] Retirer redirect méthode() dépréciée de t3lib_userAuth
• [API] Créer une hiérarchie d'exception pour les exceptions d'état HTTP