Alors que l'équipe continue de se développer, les informations de validation de git doivent suivre une certaine spécification de format pour faciliter l'utilisation en cas de besoin. La soumission d'informations peut facilement localiser le problème. Lors de l'examen du code, je sais également ce qu'a fait le commit, donc la standardisation du commit a de nombreux avantages, donc je n'en dirai pas plus.
Atteindre
结合 git hook 实现在 git commit 阶段检查输入是否符合规范，符合通过，反之提示
Des outils
commitlint: utilisé pour vérifier les informations de commit, définir l'
outil "standard", "classification" husky: hook, utilisé dans les phases git-commit et git-push
Normes
Les types communs selon commitlint-config-conventionnel (basés sur les conventions angulaires) sont les suivants:
build: modifier le système de construction du projet (xcodebuild, webpack, glut, etc.) soumission •
ci: modifier le processus d'intégration continue du projet (Kenkins, Travis, etc.)
corvée de soumission : processus de construction ou changements d'outils auxiliaires •
docs: soumission de documentation documents)
feat: nouvelles fonctionnalités (la fonctionnalité)
CORRECTIF: • bug de réparation
PERFORM: la performance, l' expérience pertinente présentent
refactor: refactorisation
revert: un rollback présenté plus tôt •
style: les modifications de code ne modifient pas la logique du programme, le principal C'est l'optimisation et la modification du style
: développement lié aux tests
Non recommandé
Si vous souhaitez désactiver la vérification pour une certaine soumission, vous pouvez ajouter le paramètre --no-verify. git commit --no-verify -m "xxx"
