Будучи постоянным пользователем ESLint, я знаю важность спецификаций. Однако при сдаче нового проекта меня свела с ума спецификация Git Commit. Только тогда я осознал свою халатность, поэтому у меня появилась идея выяснить это.
1. Зачем нужны спецификации?
Нет правил и кругов, как и программирование.
Если у вас есть проект, который вы пишете сами от начала до конца, вы можете писать все, что хотите, никто не может вам мешать. Но если в командной работе каждый проявит свою индивидуальность, то в коде будет бардак, а хороший проект будет загублен. Будь то разработка или дальнейшее обслуживание, это будет катастрофа.
В это время кто-то предложил, почему бы не унифицировать стандарт, и все должны следовать этому стандарту. тогдаESLint
,JSHint
Другие инструменты кода выросли как грибы после дождя, и они стали обязательными для создания проекта.
Git Commit
Спецификация может быть не такой уж и преувеличенной, но если вы видите много плохого при откатеCommit
, я боюсь, что это будет раздражать. Поэтому строго соблюдайте нормы, приносите пользу другим и приносите пользу себе.
2. Особые правила
Сначала рассмотрим формулу:
<type>(<scope>): <subject>
-
type
- для иллюстрации
commit
категории разрешены только следующие 7 логотипов.feat:新功能(feature) fix:修补bug docs:文档(documentation) style: 格式(不影响代码运行的变动) refactor:重构(即不是新增功能,也不是修改bug的代码变动) test:增加测试 chore:构建过程或辅助工具的变动
- для иллюстрации
-
scope
- для иллюстрации
commit
Объем влияния, такой как уровень данных, уровень управления, уровень представления и т. д., варьируется от проекта к проекту.
- для иллюстрации
- subject
- да
commit
Краткое описание цели, не более 50 символов.1.以动词开头,使用第一人称现在时,比如change,而不是changed或changes 2.第一个字母小写 3.结尾不加句号(.)
- да
Нормативная ссылка взята из статьи г-на Жуань Ифэна:Сообщение фиксации и руководство по написанию журнала изменений.
3. Обработка исключений
Давайте сначала взглянем на это напоминание об исключении:
INVALID COMMIT MSG: does not match "<type>(<scope>): <subject>" !
jartto:fix bug
Это предупреждение сообщается здесь из-за двух проблем с моей фиксацией:
Во-первых, использование ключевых слов вне спецификации;
Во-вторых, очень подробная проблема, jartto: после пробела не хватает;
В это время я вспомнил, что в то время подача была неудачной, и подача была принудительной в спешке, поэтому будущие подачи будут содержать это исключение. Это примерно означает:
Ваш предыдущий коммит не выполнен ~ Ваш предыдущий коммит не выполнен ~ Ваш предыдущий коммит не выполнен
В настоящее время это очень раздражает Мы можем только исправить предыдущие ошибки, так как же действовать?
4. Как изменить информацию о предыдущей фиксации?
Это не очень сложно, нам просто нужно сделать это:
1. Временно сохранить рабочий статус, не связанный с текущей веткой
git stash
2. будетHEAD
Перейдите к тому, который нужно изменитьcommit
начальство
git rebase 9633cf0919^ --interactive
3. Найдите, что нужно изменитьcommit
, первая строчкаpick
изменить наedit
4. Начните работать над своимbug
5.git add
Добавить измененные файлы в staging
6.git commit –amend
Добавить изменения для фиксации
7.git rebase –continue
переехатьHEAD
вернуться к последнемуcommit
8. Восстановить предыдущее рабочее состояние
git stash pop
Вы закончили, вы хотите пересмотреть весь коммит и сбежать~
Ссылка здесь из:Изменить журнал фиксации и содержимое
5. Использование в проекте
В это время снова возникает вопрос, почему появляется предупреждение, когда я его подаю, и как это делается?
В это время нам нуженNode
плагинvalidate-commit-msg
проверить проектCommit message
Это стандарт.
1. Сначала установите плагин:
npm install --save-dev validate-commit-msg
2. Используйте метод 1, установите.vcmrc
документ:
{
"types": ["feat", "fix", "docs", "style", "refactor", "perf", "test", "build", "ci", "chore", "revert"],
"scope": {
"required": false,
"allowed": ["*"],
"validate": false,
"multiple": false
},
"warnOnFail": false,
"maxSubjectLength": 100,
"subjectPattern": ".+",
"subjectPatternErrorMsg": "subject does not match subject pattern!",
"helpMessage": "",
"autoFix": false
}
3. Используйте метод 2: напишитеpackage.json
{
"config": {
"validate-commit-msg": {
/* your config here */
}
}
}
4. Но если мы хотим автоматически использоватьghooks
А как насчет хуковых функций?
{
…
"config": {
"ghooks": {
"pre-commit": "gulp lint",
"commit-msg": "validate-commit-msg",
"pre-push": "make test",
"post-merge": "npm install",
"post-rewrite": "npm install",
…
}
}
…
}
существуетghooks
Мы можем многое, конечно, не толькоvalidate-commit-msg
Ой.Для получения более подробной информации см.:validate-commit-msg
6. Роль спецификации фиксации
1. Предоставьте больше информации для облегчения расследования и отката;
2. Отфильтруйте ключевые слова и быстро найдите;
3. Удобно формировать документы;
7. Создайте журнал изменений
в видевышеВ сгенерированной документации упоминалось, что если бы все наши коммиты соответствовали спецификации, это было бы просто. Созданный документ состоит из следующих трех разделов:
- New features
- Bug fixes
- Breaking changes.
В каждом разделе будут перечислены соответствующиеcommit
, и есть указатели на нихcommit
ссылка на. Конечно, сгенерированная документация допускает ручное изменение, поэтому вы можете добавить другой контент перед публикацией.
Здесь нужны инструментыConventional ChangelogгенерироватьChange log
:
npm install -g conventional-changelog
cd jartto-domo
conventional-changelog -p angular -i CHANGELOG.md -w
Для удобства можно записатьpackage.json
изscripts
поле.
{
"scripts": {
"changelog": "conventional-changelog -p angular -i CHANGELOG.md -w -r 0"
}
}
Таким образом, его легко использовать:
npm run changelog
На данный момент все наши проблемы решены, 🍻Ура~
8. Резюме
Прочитав статью, вы все еще будете такими безрассудными? Вы также можете написать все, что хотитеCommit
? ты все еще будешьgit commit -m "hello jartto"
Представлять на рассмотрение?
Ответ нет, потому что с функцией хука у вас нет шансов, иначе будет бесконечное восстановлениеCommit
. Это может развить хорошую привычку подчиняться, 🙈~