Спецификации коммитов Git, которые вы можете игнорировать

Git спецификация кода

Будучи постоянным пользователем 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. Это может развить хорошую привычку подчиняться, 🙈~