xsteadfastx/conventionalcommits.org
1
0
Fork 0
mirror of https://github.com/conventional-commits/conventionalcommits.org.git synced 2024-11-14 18:45:13 +01:00
Code Issues Projects Releases Wiki Activity

fix(link): fix The Angular convention link for all languages

Browse Source
This commit is contained in:
konevtsov 2024-10-22 18:42:06 +07:00 committed by GitHub
parent d9568556e9
commit 547593beb1
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
11 changed files with 31 additions and 32 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
content/v1.0.0-beta.4/index.fr.md
View File

@ -36,7 +36,7 @@ consommateurs de votre bibliothèque:
1. **feat:** un commit de _type_ `feat` introduit une nouvelle fonctionnalité dans le code (cela est en corrélation avec [`MINOR`](http://semver.org/#summary) en versioning sémantique).
1. **BREAKING CHANGE:** un commit qui a le texte `BREAKING CHANGE:` qui est facultatif au début du texte ou section de pied de page introduit un changement cassant l'API (cela est en corrélation avec [`MAJOR`](http://semver.org/#summary) en versioning sémantique).
Un changement radical peut faire partie des commits de n'importe quel type.
1. Others: commit de _types_ autre que `fix:` et `feat:` sont autorisés, par exemple [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (basé sur [the Angular convention](https://github.com/angular/angular/blob/68a6a07/CONTRIBUTING.md#commit)) recommande `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, et d'autres.
1. Others: commit de _types_ autre que `fix:` et `feat:` sont autorisés, par exemple [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (basé sur [the Angular convention](https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit)) recommande `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, et d'autres.
Nous recommandons également `improvement` pour les commits qui améliorent une implémentation en cours sans ajouter de nouvelle fonctionnalité ou correction de bogue. Remarquez que ces types ne sont pas prescrits par la spécification de Conventional Commits et n'ont aucun effet implicite dans la gestion des versions sémantiques (à moins qu'ils ne comportent un BREAKING CHANGE).
<br />

2
content/v1.0.0-beta.4/index.hy.md
View File

@ -52,7 +52,7 @@ fix) մասին տեղեկացնելու համար (այն փոխկապակցվ
4. Ուրիշ տեսակներ. կարելի է օգտագործել նաև վերը նշվածներից տարբերվող
_ՏԵՍԱԿ_ ունեցող (`fix:` և `feat:`) «commit»֊ներ, օրինակ՝
[@commitlint-config-conventional](https://github.com/marionebl/commitlint/tree/master/%40commitlint/config-conventional)֊ը
(հիմնված է [Angular convention](https://github.com/angular/angular/blob/68a6a07/CONTRIBUTING.md#commit)֊ի վրա)
(հիմնված է [Angular convention](https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit)֊ի վրա)
առաջարկում է օգագործել են նաև՝ `chore:`, `docs:`, `style:`, `refactor:`,
`perf:`, `test:` և այլ _ՏԵՍԱԿԻ_ «commit»֊ներ։

4
content/v1.0.0-beta.4/index.id.md
View File

@ -34,7 +34,7 @@ konsumen perpustakaan anda:
1. **feat:** komit _tipe_ `feat` memperkenalkan suatu fitur (feature) baru dalam kode anda (ini berkolerasi dengan [`MINOR`](http://semver.org/#summary) di semantic versioning).
1. **BREAKING CHANGE:** komit yang berisi teks `BREAKING CHANGE:` di awal bagian opsi badan atau kaki mengenalkan merusak perubahan API (ini berkolerasi dengan [`MAJOR`](http://semver.org/#summary) di semantic versioning).
BREAKING CHANGE dapat menjadi bagian dari komit _tipe_ apapun.
1. Lainya: komit dengan _tipe-tipe_ selain dari `fix:` and `feat:` diperbolehkan, misalnya [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (berdasarkan pada [Angular convention](https://github.com/angular/angular/blob/68a6a07/CONTRIBUTING.md#commit)) direkomendasikan `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, dan lainya.
1. Lainya: komit dengan _tipe-tipe_ selain dari `fix:` and `feat:` diperbolehkan, misalnya [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (berdasarkan pada [Angular convention](https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit)) direkomendasikan `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, dan lainya.
Kami juga merekomendasikan `improvement` untuk komit yang meningkatkan implementasi saat ini tanpa menambahkan fitur baru atau memperbaiki celah (bug).
Perhatikan bahwa tipe-tipe ini tidak di amanatkan oleh spesifikasi conventional commits, dan tidak ada efek implisit dalam semantic versioning (kecuali mereka termasuk BREAKING CHANGE).
@ -96,7 +96,7 @@ per baris.
1. Deskripsi HARUS (MUST) disediakan setelah `BREAKING CHANGE: `, menggambarkan apa yang telah berubah tentang API, misalnya, _BREAKING CHANGE: environment variables now take precedence over config files._
1. Tipe selain `feat` dan `fix` BISA (MAY) digunakan dalam pesan komit anda.
1. Unit-unit informasi yang membentuk conventional commits TIDAK BOLEH (MUST NOT) diperlakukan case sensitif oleh pelaksana, dengan pengecualian BREAKING CHANGE yang HARUS (MUST) huruf besar.
1. `!` BISA (MAY) ditambakan sebelum `:` dalam awalan tipe/cakupan, untuk menarik perhatian pada breaking changes. `BREAKING CHANGE: description` HARUS (MUST) dimasukan kedalam badan
1. `!` BISA (MAY) ditambakan sebelum `:` dalam awalan tipe/cakupan, untuk menarik perhatian pada breaking changes. `BREAKING CHANGE: description` HARUS (MUST) dimasukan kedalam badan
atau kaki,bersama dengan `!` di awalan.
## Mengapa menggunakan Conventional Commits

2
content/v1.0.0-beta.4/index.it.md
View File

@ -34,7 +34,7 @@ Il commit contiene i seguenti elementi strutturali, allo scopo di comunicare l'i
1. **feat:** un commit di _tipo_ `feat` introduce una nuova funzionalità al codice (correlato al [`MINOR`](http://semver.org/#summary) in un versionamento semver).
1. **BREAKING CHANGE:** un commit che contiene il testo `BREAKING CHANGE:` all'inizio delle sezioni opzionali _corpo_ o _piè di pagina_, introduce una breaking API change (correlato al [`MAJOR`](http://semver.org/#summary) in un versionamento semver).
Una _BREAKING CHANGE_ può essere parte di un commit di qualsiasi _tipo_.
1. Extra: sono ammessi ulteriori _tipi_ oltre `fix:` e`feat:`, per esempio [commitlint-config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (che si basa sulla [convenzione Angular](https://github.com/angular/angular/blob/68a6a07/CONTRIBUTING.md#commit)) raccomanda `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, ed altri.
1. Extra: sono ammessi ulteriori _tipi_ oltre `fix:` e`feat:`, per esempio [commitlint-config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (che si basa sulla [convenzione Angular](https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit)) raccomanda `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, ed altri.
Raccomandiamo anche `improvement` per commit che migliorano un'implementazione esistente senza aggiungere nuove funzionalità o risolvere un errore.
Notare che questi _tipi_ non sono mantenuti da questa specifica, e non hanno un effetto sul versionamento semver (a meno che non introducano una _BREAKING CHANGE_).
<br />

2
content/v1.0.0-beta.4/index.ja.md
View File

@ -46,7 +46,7 @@ Conventional Commitsの仕様は、コミットメッセージのための軽量
1. **BREAKING CHANGE:** 本体または脚注の冒頭に `BREAKING CHANGE:` という内容があるコミットは、APIの重大な変更を意味できます。(セマンティックバージョン管理における[`MAJOR`](http://semver.org/#summary)に相当します)
`BREAKING CHANGE` はあらゆる _型_ のコミットに含めることができます。
1. Others: `fix:` and `feat:` 以外のコミット _型_ を許容します、例えば [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) ([Angularの規約](https://github.com/angular/angular/blob/68a6a07/CONTRIBUTING.md#commit)ベース)は `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, などがあります。
1. Others: `fix:` and `feat:` 以外のコミット _型_ を許容します、例えば [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) ([Angularの規約](https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit)ベース)は `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, などがあります。
新しい機能の追加やバグを修正ではなく、現在の実装を改善するコミットには `improvement` をおすすめします。

2
content/v1.0.0-beta.4/index.ko.md
View File

@ -30,7 +30,7 @@ Conventional Commits 스펙은 커밋 메시지에 곁들여진 가벼운 컨벤
1. **fix:** 코드베이스에서 버그를 패치하는 `fix` _타입_ 의 커밋 (이는 유의적 버전에서의 [`PATCH`](http://semver.org/#summary)와 관련이 있습니다).
1. **feat:** 코드베이스에서 새 기능이 추가되는 `feat` _타입_ 의 커밋 (이는 유의적 버전에서의 [`MINOR`](http://semver.org/#summary)와 관련이 있습니다).
1. **BREAKING CHANGE:** 본문이나 꼬리말의 시작 부분에 `BREAKING CHANGE:`이라는 문자열을 가진 커밋은 커다란 API 변경 있다는 것을 의미합니다 (이는 유의적 버전에서의 [`MAJOR`](http://semver.org/#summary)와 관련이 있습니다). 어떤 커밋 타입이라도 BREAKING CHANGE는 해당 커밋의 일부가 될 수 있습니다.
1. 다른 타입: `fix:`와 `feat:` 이외의 커밋 타입을 말합니다, 예를 들어 [앵귤러 컨벤션](https://github.com/angular/angular/blob/68a6a07/CONTRIBUTING.md#commit)을 기반으로 하는 [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional)에서는 `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:` 등의 타입을 사용할 것을 권고하고 있습니다.
1. 다른 타입: `fix:`와 `feat:` 이외의 커밋 타입을 말합니다, 예를 들어 [앵귤러 컨벤션](https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit)을 기반으로 하는 [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional)에서는 `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:` 등의 타입을 사용할 것을 권고하고 있습니다.
또한, 새로운 기능이나 버그 수정없이 현재 구현체를 개선하는 커밋에 대해서는 `improvement`을 사용하는 것이 좋습니다. 이 타입은 BREAKING CHANGES를 포함하지 않는 한 Conventional Commits 스펙에 의해 강제되는 부분은 아니고 유의적 버전에도 암묵적 영향을 가지지 않습니다.
<br />

2
content/v1.0.0-beta.4/index.md
View File

@ -34,7 +34,7 @@ consumers of your library:
1. **feat:** a commit of the _type_ `feat` introduces a new feature to the codebase (this correlates with [`MINOR`](http://semver.org/#summary) in semantic versioning).
1. **BREAKING CHANGE:** a commit that has the text `BREAKING CHANGE:` at the beginning of its optional body or footer section introduces a breaking API change (correlating with [`MAJOR`](http://semver.org/#summary) in semantic versioning).
A BREAKING CHANGE can be part of commits of any _type_.
1. Others: commit _types_ other than `fix:` and `feat:` are allowed, for example [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (based on the [Angular convention](https://github.com/angular/angular/blob/68a6a07/CONTRIBUTING.md#commit)) recommends `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, and others.
1. Others: commit _types_ other than `fix:` and `feat:` are allowed, for example [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (based on the [Angular convention](https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit)) recommends `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, and others.
We also recommend `improvement` for commits that improve a current implementation without adding a new feature or fixing a bug.
Notice these types are not mandated by the conventional commits specification, and have no implicit effect in semantic versioning (unless they include a BREAKING CHANGE).

3
content/v1.0.0-beta.4/index.pt-br.md
View File

@ -42,7 +42,7 @@ utilizador da sua biblioteca:
do versionamento semântico). Uma BREAKING CHANGE pode fazer parte de commits de qualquer _tipo_.
1. Outros: _tipos_ adicionais são permitidos além de `fix:` e `feat:`, por exemplo
[@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional)
(baseado na [Convenção do Angular](https://github.com/angular/angular/blob/68a6a07/CONTRIBUTING.md#commit))
(baseado na [Convenção do Angular](https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit))
recomenda-se `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, entre outros.
Também recomendamos `improvement` para commits que melhoram uma implementação
@ -202,4 +202,3 @@ Não! Se você usar um workflow de git baseado em squash, os mantenedores poder
isso é fazer com que o git faça squash dos commits automaticamente de um pull
request e apresente um formulário para o mantenedor inserir a mensagem do commit
apropriada para o merge.

40
content/v1.0.0-beta.4/index.ru.md
View File

@ -10,9 +10,9 @@ aliases: ["/ru/"]
Conventional Commits - это простое соглашение о том, как нужно писать сообщения commit'ов.
Оно описывает простой набор правил для создания понятной истории commit'ов,
а также позволяет проще разрабатывать инструменты автоматизации, основанные на
истории commit'ов. Данное соглашение совместимо с [SemVer](http://semver.org),
истории commit'ов. Данное соглашение совместимо с [SemVer](http://semver.org),
описывая новые функции (features), исправления (fixes) и изменения, нарушающие
обратную совместимость (breaking changes) в сообщениях commit'ов.
обратную совместимость (breaking changes) в сообщениях commit'ов.
Сообщения commit'ов должны быть следующей структуры:
@ -31,23 +31,23 @@ Conventional Commits - это простое соглашение о том, к
Commit'ы могут содержать следующие структурные элементы для сообщений пользователям
вашей библиотеки:
1. **fix:** commit _типа_ `fix` исправляет ошибку (bug) в вашем коде
1. **fix:** commit _типа_ `fix` исправляет ошибку (bug) в вашем коде
(он соответствует [`PATCH`](http://semver.org/#summary) в SemVer)
1. **feat:** commit _типа_ `feat` добавляет новую функцию (feature) в ваш код
1. **feat:** commit _типа_ `feat` добавляет новую функцию (feature) в ваш код
(он соответствует [`MINOR`](http://semver.org/#summary) в SemVer).
1. **BREAKING CHANGE:** commit, который содержит текст `BREAKING CHANGE:`
1. **BREAKING CHANGE:** commit, который содержит текст `BREAKING CHANGE:`
в начале своего не обязательного тела сообщения (body) или в подвале (footer),
добавляет изменения, нарушающие обратную совместимость вашего API
(он соответствует [`MAJOR`](http://semver.org/#summary) в SemVer).
BREAKING CHANGE может быть частью commit'а любого _типа_.
1. Другое: commit'ы с _типами_, которые отличаются от `fix:` и `feat:`,
также разрешены. Например, [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional)
(основанный на [The Angular convention](https://github.com/angular/angular/blob/68a6a07/CONTRIBUTING.md#commit))
1. Другое: commit'ы с _типами_, которые отличаются от `fix:` и `feat:`,
также разрешены. Например, [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional)
(основанный на [The Angular convention](https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit))
рекомендует: `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, и другие.
Мы также рекомендуем `improvement` для commit'ов, которые вносят улучшения в текущую
реализацию без добавления новых функций и исправления ошибок. Обратите внимание, что
данный тип не описывается данной спецификацией и не имеет эффекта в SemVer
данный тип не описывается данной спецификацией и не имеет эффекта в SemVer
(за исключением, когда он включает BREAKING CHANGE).
<br />
Контекст (scope) может быть объявлен рядом с типом commit'а для добавления дополнительной
@ -92,18 +92,18 @@ closes issue #12
Слова “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, и “OPTIONAL” в данном документе должны интерпретироваться как в [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
1. Commit'ы должны (MUST) начинаться с типа, который является существительным: `feat`, `fix`, и т.д.,
1. Commit'ы должны (MUST) начинаться с типа, который является существительным: `feat`, `fix`, и т.д.,
за которым следуют не обязательное (OPTIONAL) указание контекста (scope), двоеточие и пробел.
1. Тип `feat` должен (MUST) использоваться, когда commit добавляет новый функционал (feature) в
1. Тип `feat` должен (MUST) использоваться, когда commit добавляет новый функционал (feature) в
ваше приложение или библиотеку.
1. Тип `fix` должен (MUST) использоваться, когда commit исправляет ошибку (fix)
1. Тип `fix` должен (MUST) использоваться, когда commit исправляет ошибку (fix)
в вашем приложении или библиотеке.
1. Контекст (scope) может (MAY) следовать после типа. Контекст
1. Контекст (scope) может (MAY) следовать после типа. Контекст
должен (MUST) быть существительным, заключенным в круглые скобки, описывающий
часть кодовой базы, которую затронул commit. Например, `fix(parser):`.
1. Описание должно (MUST) следовать через пробел сразу же после типа/контекста.
Описание - это краткая выжимка об изменениях кода, например, _fix: array parsing issue when multiple spaces were contained in string._
1. Тело (body) commit'а может (MAY) следовать после короткого описания,
1. Тело (body) commit'а может (MAY) следовать после короткого описания,
добавляя дополнительную информацию об изменениях в коде. Тело должно (MUST) отделяться
от короткого описания одной пустой строкой.
1. Подвал (footer) может (MAY) быть представлен одной или несколькими строками после тела commit'а.
@ -114,14 +114,14 @@ closes issue #12
указаны в самом начале тела (body) или в начале одной из строк подвала (footer).
Изменения, нарушающие обратную совместимость, должны (MUST) начинаться с текста,
написанного прописными буквами, BREAKING CHANGE, за которым должны следовать двоеточие и пробел.
1. Описание изменений, нарушающих обратную совместимость, должно (MUST) следовать после
1. Описание изменений, нарушающих обратную совместимость, должно (MUST) следовать после
`BREAKING CHANGE: `. В нем должно содержаться то, что изменилось в API. Например,
_BREAKING CHANGE: environment variables now take precedence over config files._
1. Типы отличные от `feat` и `fix` могут (MAY) быть использованы в ваших commit'ах.
1. Единицы информации, которые составляют обычные commit'ы, не должны (MUST NOT)
1. Единицы информации, которые составляют обычные commit'ы, не должны (MUST NOT)
трактоваться разработчиками как регистрозависимые, за исключением BREAKING CHANGE,
который всегда должен быть написан прописными буквами.
1. Знак `!` может (MAY) быть добавлен перед `:` в тип/контекст, чтоб обратить внимание
1. Знак `!` может (MAY) быть добавлен перед `:` в тип/контекст, чтоб обратить внимание
на изменения. Строка `BREAKING CHANGE: description` должна (MUST) быть добавлена в
тело (body) или подвал (footer), если используется `!` в префиксе.
@ -131,7 +131,7 @@ _BREAKING CHANGE: environment variables now take precedence over config files._
* Автоматическое определение семантической версии SemVer (на основе типов совершенных commit'ов).
* Коммуникация о характере изменений между товарищами по команде, общественностью и другими заинтересованными сторонами.
* Автоматически срабатываемый процесс сборки и публикации.
* Людям проще участвовать в вашем проекте, потому что им доступна более структурированная история коммитов.
* Людям проще участвовать в вашем проекте, потому что им доступна более структурированная история коммитов.
## FAQ
@ -156,12 +156,12 @@ _BREAKING CHANGE: environment variables now take precedence over config files._
### Могут ли Conventional Commits заставить разработчиков ограничивать их типы commit'ов, потому что им придется думать об этих типах?
Conventional Commits побуждают делать больше commit'ов с определенными типами, такими как `fix`. Кроме того, гибкость
Conventional Commits побуждают делать больше commit'ов с определенными типами, такими как `fix`. Кроме того, гибкость
Conventional Commits позволяет вашей команде создавать свои собственные типы и изменять их с течением времени.
### Как это связано с правилами семантического управления версиями [SemVer](http://semver.org)?
`fix` тип commit'а должен быть отражен в `PATCH`-релизе. `feat` тип commit'а должен быть отражен в `MINOR`-релизе.
`fix` тип commit'а должен быть отражен в `PATCH`-релизе. `feat` тип commit'а должен быть отражен в `MINOR`-релизе.
Commit'ы с `BREAKING CHANGE` в теле или подвале, независимо от типа, должны быть отражены в `MAJOR`-релизе.
### Как я должен версионировать мои расширения к спецификации Conventional Commits, например, `@jameswomack/conventional-commit-spec`?

2
content/v1.0.0-beta.4/index.zh-hans.md
View File

@ -33,7 +33,7 @@ aliases: ["/zh/", "/zh-hans/"]
2. **feat:** _类型_ 为 `feat` 的提交表示在代码库中新增了一个功能（这和语义化版本中的 [`MINOR`](https://semver.org/lang/zh-CN/#%E6%91%98%E8%A6%81) 相对应）。
3. **BREAKING CHANGE:** 在可选的正文或脚注的起始位置带有 `BREAKING CHANGE:` 的提交，表示引入了破坏性 API 变更（这和语义化版本中的 [`MAJOR`](https://semver.org/lang/zh-CN/#%E6%91%98%E8%A6%81) 相对应）。
破坏性变更可以是任意 _类型_ 提交的一部分。
1. **其它情况:** 除 `fix:` 和 `feat:` 之外的提交 _类型_ 也是被允许的，例如 [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional)（基于 [Angular 约定](https://github.com/angular/angular/blob/68a6a07/CONTRIBUTING.md#commit)）中推荐的 `chore:`、`docs:`、`style:`、`refactor:`、`perf:`、`test:` 及其他标签。
1. **其它情况:** 除 `fix:` 和 `feat:` 之外的提交 _类型_ 也是被允许的，例如 [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional)（基于 [Angular 约定](https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit)）中推荐的 `chore:`、`docs:`、`style:`、`refactor:`、`perf:`、`test:` 及其他标签。
我们也推荐使用`improvement`，用于对当前实现进行改进而没有添加新功能或修复错误的提交。
请注意，这些标签在约定式提交规范中并不是强制性的。并且在语义化版本中没有隐式的影响（除非他们包含 BREAKING CHANGE）。
<br />

2
content/v1.0.0-beta.4/index.zh-hant.md
View File

@ -33,7 +33,7 @@ aliases: ["/zh-hant/"]
1. **feat:** 為 `feat` _類型_ 的提交，表示對程式增加了一個功能 (對應到語意化版本中的 [`MINOR`](http://semver.org/#summary))。
1. **BREAKING CHANGE:** 在可選的正文或是頁腳的起始文字為 `BREAKING CHANGE:` 的提交，表示有重大的 API 變更 (對應到語意化版本中的 [`MAJOR`](http://semver.org/#summary))。
重大變更可以是任何 _類型_ 提交的一部分。
1. 其他: 除 `fix:` 與 `feat:` 以外，其他的提交 _類型_ 也是被允許的，例如 [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (基於 [Angular 慣例](https://github.com/angular/angular/blob/68a6a07/CONTRIBUTING.md#commit)) 中推薦的 `chore:`、`docs:`、`style:`、`refactor:`、`perf:`、`test:` 以及更多。
1. 其他: 除 `fix:` 與 `feat:` 以外，其他的提交 _類型_ 也是被允許的，例如 [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (基於 [Angular 慣例](https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit)) 中推薦的 `chore:`、`docs:`、`style:`、`refactor:`、`perf:`、`test:` 以及更多。
我們也推薦對那些沒有增加新功能或是修正臭蟲而是改善目前實作的提交使用 `improvement`。
請注意，這些類型在慣例式提交規範中並不是強制性的，且在語意化版本中也沒有隱含的作用 (除非它們包含 BREAKING CHANGE)。