mirror of
https://github.com/conventional-commits/conventionalcommits.org.git
synced 2024-11-15 02:45:15 +01:00
Merge branch 'master' into master
This commit is contained in:
Damiano Petrungaro
GitHub
commit
a72c239217
@ -1,38 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<project version="4">
|
||||
<component name="ChangeListManager">
|
||||
<list default="true" id="c2ad3f94-db0d-4df0-82cb-bcfc09434809" name="Default Changelist" comment="" />
|
||||
<option name="SHOW_DIALOG" value="false" />
|
||||
<option name="HIGHLIGHT_CONFLICTS" value="true" />
|
||||
<option name="HIGHLIGHT_NON_ACTIVE_CHANGELIST" value="false" />
|
||||
<option name="LAST_RESOLUTION" value="IGNORE" />
|
||||
</component>
|
||||
<component name="GOROOT" path="/usr/local/go" />
|
||||
<component name="Git.Settings">
|
||||
<option name="RECENT_GIT_ROOT_PATH" value="$PROJECT_DIR$" />
|
||||
</component>
|
||||
<component name="MacroExpansionManager">
|
||||
<option name="directoryName" value="ue4nx00h" />
|
||||
</component>
|
||||
<component name="ProjectId" id="1aoIzNyhGuamEwP7GGHxfA5ZviZ" />
|
||||
<component name="ProjectViewState">
|
||||
<option name="hideEmptyMiddlePackages" value="true" />
|
||||
<option name="showExcludedFiles" value="true" />
|
||||
<option name="showLibraryContents" value="true" />
|
||||
</component>
|
||||
<component name="PropertiesComponent">
|
||||
<property name="RunOnceActivity.ShowReadmeOnStart" value="true" />
|
||||
<property name="WebServerToolWindowFactoryState" value="false" />
|
||||
<property name="go.import.settings.migrated" value="true" />
|
||||
<property name="go.sdk.automatically.set" value="true" />
|
||||
<property name="last_opened_file_path" value="$PROJECT_DIR$/archetypes" />
|
||||
</component>
|
||||
<component name="RecentsManager">
|
||||
<key name="CopyFile.RECENT_KEYS">
|
||||
<recent name="$PROJECT_DIR$/archetypes" />
|
||||
</key>
|
||||
</component>
|
||||
<component name="TypeScriptGeneratedFilesManager">
|
||||
<option name="version" value="1" />
|
||||
</component>
|
||||
</project>
|
||||
@ -178,9 +178,9 @@ languages:
|
||||
weight: 9
|
||||
languageName: "Français"
|
||||
title: Commits Conventionnels
|
||||
description: Une spécification ajoutant une signification lisible pour l'humain et pour la machine dans les messages des commits
|
||||
description: Une spécification qui permet une signification lisible pour l'humain et pour la machine dans les messages des commits
|
||||
actions:
|
||||
- label: Voir la spécification
|
||||
- label: Spécification complète
|
||||
url: '#spécification'
|
||||
- label: GitHub
|
||||
url: 'https://github.com/conventional-commits/conventionalcommits.org'
|
||||
|
||||
@ -57,10 +57,13 @@ The first draft of this specification has been written in collaboration with som
|
||||
* [Jenkins](https://github.com/jenkinsci/git-changelog-plugin)
|
||||
* [Command Line](https://github.com/tomasbjerre/git-changelog-command-line)
|
||||
* [Docker](https://hub.docker.com/r/tomasbjerre/git-changelog-command-line)
|
||||
* [GitHub Action](https://github.com/tomasbjerre/git-changelog-github-release)
|
||||
* [Cocogitto](https://github.com/oknozor/cocogitto): Cocogitto is a set of cli tools for the conventional commits and semver specifications.
|
||||
* [Conventional Commits Linter](https://gitlab.com/DeveloperC/conventional_commits_linter): A tooling and language agnostic Git commit linter for the _Conventional Commits_ specification.
|
||||
* [Uplift](https://github.com/gembaadvantage/uplift): Semantic versioning the easy way. Powered by Conventional Commits. Built for use with CI.
|
||||
* [Monopub](https://github.com/thi-ng/monopub): Conventional Commits-driven release tool for monorepo releases, versioning & changelog generation
|
||||
* [Monopub](https://github.com/thi-ng/monopub): Conventional Commits-driven release tool for monorepo releases, versioning & changelog generation.
|
||||
* [git-cliff](https://git-cliff.org/): A highly customizable changelog generator written in Rust that can generate changelog files for any Git repository that follows the _Conventional Commits_ specification
|
||||
* [cz-git](https://github.com/Zhengqbbb/cz-git): A customizable CLI tool for generating commit messages following Conventional Commits.
|
||||
|
||||
## Projects Using Conventional Commits
|
||||
|
||||
|
||||
@ -264,6 +264,7 @@ Configurable and usable for PHP projects as a composer dependency or usable glob
|
||||
* [Jenkins](https://github.com/jenkinsci/git-changelog-plugin)
|
||||
* [Command Line](https://github.com/tomasbjerre/git-changelog-command-line)
|
||||
* [Docker](https://hub.docker.com/r/tomasbjerre/git-changelog-command-line)
|
||||
* [GitHub Action](https://github.com/tomasbjerre/git-changelog-github-release)
|
||||
* [Cocogitto](https://github.com/oknozor/cocogitto): Cocogitto is a set of cli tools for the conventional commits and semver specifications.
|
||||
* [Conventional Commits Linter](https://gitlab.com/DeveloperC/conventional_commits_linter): A tooling and language agnostic Git commit linter for the _Conventional Commits_ specification.
|
||||
* [Uplift](https://github.com/gembaadvantage/uplift): Semantic versioning the easy way. Powered by Conventional Commits. Built for use with CI
|
||||
|
||||
@ -36,11 +36,11 @@ 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 />
|
||||
Un scope peut être fournie au type d'un commit, pour fournir des informations contextuelles supplémentaires et
|
||||
Un scope peut être fourni au type d'un commit, pour fournir des informations contextuelles supplémentaires et
|
||||
le contenu entre parenthèses, par exemple, `feat (analyseur): ajout possibilité d'analyser des tableaux`.
|
||||
|
||||
## Exemples
|
||||
@ -82,12 +82,12 @@ fixes issue #12
|
||||
|
||||
Les mots clés ”DOIT” (“MUST”), “NE DOIT PAS” (“MUST NOT”), “REQUIS” (“REQUIRED”), “NE DOIT” (“SHALL”), “NE DOIT PAS” (“SHALL NOT”), “NE DEVRAIT” (“SHOULD”), “NE DEVRAIT PAS” (“SHOULD NOT”), “RECOMMANDÉ” (“RECOMMENDED”), “PEUT” (“MAY”), et “FACULTATIF” (“OPTIONAL”) dans ce document doivent être interprétés comme décrit dans [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
|
||||
|
||||
1. Les commits DOIT être préfixés par un type, qui consiste en un nom, `feat`,` fix`, etc.,
|
||||
suivi d'un côlon et d'un espace.
|
||||
1. Les commits DOIVENT être préfixés par un type, qui consiste en un nom, `feat`,` fix`, etc.,
|
||||
suivi de deux points et d'un espace.
|
||||
1. Le type `feat` DOIT être utilisé lorsqu'un commit ajoute une nouvelle fonctionnalité à votre application.
|
||||
ou bibliothèque.
|
||||
1. Le type `fix` DOIT être utilisé lorsqu'un commit représente un correctif pour votre application.
|
||||
1. Un scope facultative PEUT être fournie après un type. Un scope est une phrase décrivant
|
||||
1. Un scope facultative PEUT être fourni après un type. Un scope est une phrase décrivant
|
||||
une section du code encadrée par des parenthèses, par exemple, `fix (analyseur):`
|
||||
1. Une description DOIT suivre immédiatement le préfixe type/scope.
|
||||
La description est une brève description des modifications du code, par exemple,
|
||||
@ -121,7 +121,7 @@ Nous vous recommandons de procéder comme si vous aviez déjà publié un produi
|
||||
|
||||
### Les types dans le titre des commits sont-ils en majuscules ou en minuscules?
|
||||
|
||||
N'importe quel taille peut être utilisé, mais il est préférable d'être cohérent.
|
||||
N'importe quelle taille peut être utilisée, mais il est préférable d'être cohérent.
|
||||
|
||||
### Que dois-je faire si le commit est conforme à plus d'un type de commit?
|
||||
|
||||
@ -156,5 +156,5 @@ Dans le pire des cas, ce n'est pas la fin du monde si un commit atterrit sans re
|
||||
|
||||
### Est-ce que tous mes contributeurs doivent utiliser les spécifications de Conventional Commits ?
|
||||
|
||||
Non! Si vous utilisez un flux de travail basé sur squash sur Git, les responsables principaux peuvent nettoyer les messages des commits au fur et à mesure de leur fusion, ce qui permet de ne pas ajouter de charge de travail aux committers occasionnels.
|
||||
Non ! Si vous utilisez un flux de travail basé sur squash sur Git, les responsables principaux peuvent nettoyer les messages des commits au fur et à mesure de leur fusion, ce qui permet de ne pas ajouter de charge de travail aux committers occasionnels.
|
||||
Un processus courant consiste à ce que votre système git écrase automatiquement les commits d'une demande d'extraction et présente un formulaire permettant au responsable de la maintenance d'entrer le message du commit git approprié pour la fusion.
|
||||
|
||||
@ -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»֊ներ։
|
||||
|
||||
|
||||
@ -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).
|
||||
|
||||
@ -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 />
|
||||
|
||||
@ -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` をおすすめします。
|
||||
@ -100,7 +100,7 @@ closes issue #12
|
||||
|
||||
## 仕様
|
||||
|
||||
この文書における次の各キーワード「しなければならない（ MUST ）」、 「してはならない（ MUST NOT ）」、「要求されている（ REQUIRED ）」、 「することになる（ SHALL ）」、「することはない（ SHALL NOT ）」、 「する必要がある（ SHOULD ）」、「しないほうがよい（ SHOULD NOT ）」、 「推奨される（ RECOMMENDED ）」、「してもよい（ MAY ）」、 「選択できる（ OPTIONAL ）」は、 [RFC 2119 (IPA 日本語)](https://www.ipa.go.jp/security/rfc/RFC2119JA.html) で述べられているように 解釈されるべきものです。
|
||||
この文書における次の各キーワード「しなければならない（ MUST ）」、 「してはならない（ MUST NOT ）」、「要求されている（ REQUIRED ）」、 「することになる（ SHALL ）」、「することはない（ SHALL NOT ）」、 「する必要がある（ SHOULD ）」、「しないほうがよい（ SHOULD NOT ）」、 「推奨される（ RECOMMENDED ）」、「してもよい（ MAY ）」、 「選択できる（ OPTIONAL ）」は、 [RFC 2119 (JPNIC 日本語)](https://www.nic.ad.jp/ja/tech/ipa/RFC2119JA.html) で述べられているように 解釈されるべきものです。
|
||||
|
||||
1. コミットは _型_ から始まり、次に選択できる（ OPTIONAL ） _範囲_ と、末尾に要求されている（ REQUIRED ）コロンとスペースで成り立ちます。
|
||||
1. コミットがあなたのアプリケーションやライブラリに新しい機能を追加するとき、 _型_ は`feat`にしなければならない（ MUST ）。
|
||||
|
||||
@ -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 />
|
||||
|
||||
@ -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).
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -42,7 +42,7 @@ Commit'ы могут содержать следующие структурны
|
||||
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))
|
||||
(основанный на [The Angular convention](https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit))
|
||||
рекомендует: `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, и другие.
|
||||
|
||||
Мы также рекомендуем `improvement` для commit'ов, которые вносят улучшения в текущую
|
||||
|
||||
@ -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 />
|
||||
|
||||
@ -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)。
|
||||
|
||||
@ -113,7 +113,7 @@ Refs: #123
|
||||
|
||||
## 仕様
|
||||
|
||||
この文書におけるキーワード「しなければならない (MUST)」「してはならない (MUST NOT)」「要求されている (REQUIRED)」「することになる (SHALL)」「することはない(SHALL NOT)」「する必要がある (SHOULD)」「しないほうがよい (SHOULD NOT)」「推奨される (RECOMMENDED)」「してもよい (MAY)」「選択できる (OPTIONAL)」は [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) ([IPA 日本語訳](https://www.ipa.go.jp/security/rfc/RFC2119JA.html)) で述べられているように解釈されるべきものです。
|
||||
この文書におけるキーワード「しなければならない (MUST)」「してはならない (MUST NOT)」「要求されている (REQUIRED)」「することになる (SHALL)」「することはない(SHALL NOT)」「する必要がある (SHOULD)」「しないほうがよい (SHOULD NOT)」「推奨される (RECOMMENDED)」「してもよい (MAY)」「選択できる (OPTIONAL)」は [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) ([JPNIC 日本語訳](https://www.nic.ad.jp/ja/tech/ipa/RFC2119JA.html)) で述べられているように解釈されるべきものです。
|
||||
|
||||
1. コミットは `feat` や `fix` などの型から始まり (MUST)、その後ろにはスコープ (OPTIONAL) と `!` (OPTIONAL) が続き、その後ろにコロンとスペース (REQUIRED) が続く。
|
||||
1. コミットがあなたのアプリケーションやライブラリに新しい機能を追加するとき、型 `feat` が使われなければならない (MUST)。
|
||||
@ -131,7 +131,7 @@ Refs: #123
|
||||
1. フッターの値にはスペースと改行を含めることができる (MAY)。そして次のフッターのトークンとセパレータの組が見つかった時、以前のフッターのパースは終了しなければならない (MUST)。
|
||||
1. 破壊的変更は、コミットの型/スコープの接頭辞か、フッターによって明示されなければならない (MUST)。
|
||||
1. 破壊的変更がフッターとして含まれる場合は、大文字の BREAKING CHANGE の後ろにコロンとスペース、そしてタイトルを続けなければならない (MUST)。例: `BREAKING CHANGE: environment variables now take precedence over config files`。
|
||||
1. 破壊的変更が型/スコープの接頭辞として含まれる場合は、`:` の直前に `!` を用いて明示されねばならない (MUST)。`!` が使用すれた場合には、 フッターから `BREAKING CHANGE:` を省略してもよい (MAY)。その場合はコミットのタイトル部分で破壊的変更の内容を説明することになる (SHALL)。
|
||||
1. 破壊的変更が型/スコープの接頭辞として含まれる場合は、`:` の直前に `!` を用いて明示されねばならない (MUST)。`!` が使用された場合には、 フッターから `BREAKING CHANGE:` を省略してもよい (MAY)。その場合はコミットのタイトル部分で破壊的変更の内容を説明することになる (SHALL)。
|
||||
1. `feat` と `fix` 以外の型を使うことができる (MAY)。例: `docs: updated ref docs.`。
|
||||
1. Conventional Commits を構成する情報の単位は、大文字の `BREAKING CHANGE` を除いて、実装は大文字と小文字を区別してはならない (MUST NOT)。
|
||||
1. フッターのトークンにおいて BREAKING-CHANGE は BREAKING CHANGE と同じトークンとして解釈されなければならない (MUST)。
|
||||
|
||||
@ -1,27 +1,26 @@
|
||||
---
|
||||
draft: false
|
||||
aliases:
|
||||
- "/tr/"
|
||||
aliases: ["/tr/"]
|
||||
---
|
||||
|
||||
# Conventional Commits 1.0.0
|
||||
|
||||
## Özet
|
||||
|
||||
Conventional Commits şartnamesi, commit mesajları hakkında kolayca takip edilebilecek bir sözleşmedir.
|
||||
Otomatik araçlar yazılarak anlaşılabilecek açık bir commit geçmişi oluşturmak için kolay bir dizi kural sağlar.
|
||||
Bu sözleşme [SemVer](http://semver.org) ile uyumludur ve commit mesajlarında yeni özellik ekleme (features), hata düzeltme (fixes) ve yıkıcı değişiklik (breaking change) tanımlamalarını yapar.
|
||||
Conventional Commits yönergesi, commit mesajları hakkında kolayca takip edilebilecek bir sözleşmedir.
|
||||
Anlaşılabilir bir commit geçmişi için kolay bir dizi kurallar oluşturarak, üzerine daha kolay otomatik araçlar yazılmasını sağlar.
|
||||
Bu sözleşme, commit mesajlarında yeni özellik ekleme (features), hata düzeltme (fixes) ve köklü değişiklik (breaking changes) tanımlamalarıyla [SemVer](http://semver.org) ile uyumludur.
|
||||
|
||||
Commit mesajı aşağıdaki gibi yapılandırılmalıdır:
|
||||
|
||||
---
|
||||
|
||||
```
|
||||
<tip>[kapsam, zorunlu değil]: <açıklama>
|
||||
<tip>[isteğe bağlı kapsam alanı]: <açıklama>
|
||||
|
||||
[zorunlu olmayan mesaj metni]
|
||||
[isteğe bağlı mesaj metni]
|
||||
|
||||
[zorunlu olmayan alt metin(ler)]
|
||||
[isteğe bağlı alt metin(ler)]
|
||||
```
|
||||
|
||||
---
|
||||
@ -30,47 +29,46 @@ Commit mesajı aşağıdaki gibi yapılandırılmalıdır:
|
||||
<br>
|
||||
Commit mesajı kütüphanenizin kullanıcılarına niyet belirtmek için aşağıdaki yapısal unsurları içerir:
|
||||
|
||||
1. **fix:** `fix` *tipi* bir commit kodunuzdaki bir hatayı düzeltir (Semantik versiyonlamadaki [`PATCH`](http://semver.org/#summary) ile paraleldir).
|
||||
2. **feat:** `feat` *tipi* commit kodunuza yeni bir özellik ekler (Semantik versiyonlamadaki [`MINOR`](http://semver.org/#summary) ile paraleldir).
|
||||
3. **BREAKING CHANGE:** `BREAKING CHANGE:` ile başlayan bir alt metin ya da tip/kapsam sonuna eklenmiş bir `!` içeren commit yıkıcı bir değişiklik getiriyordur (Semantik versiyonlamadaki [`MAJOR`](http://semver.org/#summary) ile paraleldir). Bir BREAKING CHANGE harhangi bir *tip* commit içinde olabilir.
|
||||
4. `fix:` ve `feat:` dışında *tipler* de kullanılabilir. Örneğin [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) `build:`, `chore:`, `ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, ve birkaç başka tipi de tavsiye eder (bu [the Angular sözleşmesinden](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines) esinlenmiştir).
|
||||
5. `BREAKING CHANGE: <description>` dışında *alt metinler* de kullanılabilir ve [git trailer format](https://git-scm.com/docs/git-interpret-trailers) takip edilebilir.
|
||||
1. **fix:** `fix` *tipi* bir commit, kodunuzdaki bir hatayı düzeltir (Semantik versiyonlamadaki [`PATCH`](http://semver.org/#summary) ile paraleldir).
|
||||
2. **feat:** `feat` *tipi* bir commit, kodunuza yeni bir özellik ekler (Semantik versiyonlamadaki [`MINOR`](http://semver.org/#summary) ile paraleldir).
|
||||
3. **BREAKING CHANGE:** `BREAKING CHANGE:` ile başlayan bir alt metin ya da tip/kapsam sonuna eklenmiş bir `!` içeren commit köklü bir değişiklik getiriyordur (Semantik versiyonlamadaki [`MAJOR`](http://semver.org/#summary) ile paraleldir). Bir BREAKING CHANGE herhangi bir *tip* commit içinde olabilir.
|
||||
4. `fix:` ve `feat:` dışındaki *tipler* de kullanılabilir. Örneğin [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) ([Angular yönergesine göre](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) `build:`, `chore:`, `ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, ve birkaç başka tipi de tavsiye eder.
|
||||
5. `BREAKING CHANGE: <description>` dışında *alt metinler* de kullanılabilir ve [git trailer format](https://git-scm.com/docs/git-interpret-trailers)'a benzer yönergeler takip edilebilir.
|
||||
|
||||
Ek tipler Conventional Commits sözleşmesi tarafından zorunlu kılınmaz ve semantik versiyon oluşturmada örtülü bir etkisi yoktur (tabiki BREAKING CHANGE içermedikçe).
|
||||
<br><br>
|
||||
Ek bağlamsal bilgi sağlamak için bir commit türüne bir kapsam eklenebilir ve parantez içinde yer alır, Örneğin, `feat(parser): add ability to parse arrays`.
|
||||
Harici ek tipler Conventional Commits yönergesi tarafından zorunlu kılınmaz ve semantik versiyon oluşturmada tam bir etkisi yoktur (tabiki BREAKING CHANGE içermedikçe).
|
||||
<br /><br />
|
||||
Fazladan ilave bağlamsal bilgi sağlamak için bir commit türüne bir kapsam eklenebilir ve parantez içinde yer alır, Örneğin, `feat(parser): add ability to parse arrays`.
|
||||
|
||||
## Örnekler
|
||||
|
||||
### Açıklama ve yıkıcı değişiklik içeren alt metin sahibi bir commit mesajı
|
||||
### Açıklama ve köklü değişiklik içeren alt metinli bir commit mesajı
|
||||
|
||||
```
|
||||
feat: config neslelerinin birbirinden türetilmesi sağlandı
|
||||
feat: config nesnelerinin birbirinden türetilmesi sağlandı
|
||||
|
||||
BREAKING CHANGE: `extends` artık başka bir ayar dosyasından türetildiğini belirtiyor
|
||||
BREAKING CHANGE: `extends` kelimesi artık başka bir ayar dosyasından türetildiğini belirtiyor
|
||||
```
|
||||
|
||||
### Yıkıcı bir değişikliğe dikkat çeken `!` içeren commit mesajı
|
||||
### Köklü değişikliğe `!` ile dikkat çeken commit mesajı
|
||||
|
||||
```
|
||||
refactor!: Node 6 desteği kaldırıldı
|
||||
feat!: müşteriye, ürünü kargolandığında mail atma özelliği eklendi
|
||||
```
|
||||
|
||||
### Kapsamı belirtilen ve `!` ile yıkıcı değişikliğe dikkat çeken commit mesajı
|
||||
|
||||
### Kapsam içeren ve köklü değişikliğe `!` ile dikkat çeken commit mesajı
|
||||
```
|
||||
refactor(runtime)!: Node 6 desteği kaldırıldı
|
||||
feat(api)!: müşteriye, ürünü kargolandığında mail atma özelliği eklendi
|
||||
```
|
||||
|
||||
### `!` ve BREAKING CHANGE alt metni içeren commit mesajı
|
||||
### `!` ve köklü değişiklik alt metni içeren commit mesajı
|
||||
|
||||
```
|
||||
refactor!: Node 6 desteği kaldırıldı
|
||||
chore!: Node 6 desteği kaldırıldı
|
||||
|
||||
BREAKING CHANGE: Sadece Node 6 içinde olan Javascript özellikleri kullanan yerler yeniden yazılmalı.
|
||||
```
|
||||
|
||||
### Mesaj metni olamayan commit
|
||||
### Mesaj metni olamayan commit mesajı
|
||||
|
||||
```
|
||||
docs: CHANGELOG'daki yazım hataları düzeltildi
|
||||
@ -82,7 +80,7 @@ docs: CHANGELOG'daki yazım hataları düzeltildi
|
||||
feat(lang): Türkçe çeviri eklendi
|
||||
```
|
||||
|
||||
### Çok paragraflı mesaj metni ve birden çok alt metin içeren commit
|
||||
### Çok paragraflı mesaj metni ve birden çok alt metin içeren commit mesajı
|
||||
|
||||
```
|
||||
fix: bazı küçük yazım hataları düzeltildi
|
||||
@ -95,31 +93,31 @@ Reviewed-by: Z
|
||||
Refs #133
|
||||
```
|
||||
|
||||
## Şartname
|
||||
## Yönerge
|
||||
|
||||
Bu belgedeki “-MALI”, “-MAMALI”, “ZORUNLU”, “YAPALIM”, “YAPMAYALIM”, “-SAM IYI OLUR”, “-MASAM IYI OLUR”, “TAVSIYE EDILIR”, “-ABİLİRİM” ve “SEÇMELİ” kalıpları [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt)'da açıklandığı gibi yorumlanmalıdır.
|
||||
|
||||
1. Her commit mesajı bir `feat`, `fix`, vs. gibi bir tip ile başlaMALI, SEÇMELİ bir kapsam, SEÇMELİ bir `!` işareti ve ZORUNLU bir iki nokta üst üste işareti ve bir adet boşluk ile devam eder.
|
||||
2. `feat` tipi eğer commit uygulamaya ya da kütüphaneye yeni bir özellik ekliyorsa kullanılMALI.
|
||||
3. `fix` tipi eğer commit uygulamadaki bir hatayı düzeltiyorsa kullanılMALI.
|
||||
4. Tip bilgisinden sonra bir kapsam belirtilEBİLİR. Kapsam bilgisi parantez içerisinde kodun hangi bölümün değiştiğine açıklayan bir isimden oluşur. Örneğin `fix(parser):`.
|
||||
5. Açıklama tip/kapsam ön bilgilerinden sonraki iki nokta ve boşluktan hemen sonra yazılMALIdır. Yapılan değişikliği anlatan kısa bir özettir. Örneğin *fix: array parsing issue when multiple spaces were contained in string*.
|
||||
6. Kısa açıklamadan sonra, kod değişiklikleri hakkında ek bağlamsal bilgiler sağlayan daha uzun bir commit mesajı metni yazılABİLİR. Mesaj metni açıklamadan sonra boş bir satıra başlaMALIDIR.
|
||||
7. Bir commit mesaj metni serbest şekildedir ve boş bir satırla ayrılan herhangi bir sayıda paragraftan oluşABİLİR.
|
||||
8. Bir ya da birden fazla alt metin mesaj metninden bir boş satır sonra koyulABİLİR. Her alt metin bir anahtar kelime ile başlaMALI, anahtar kelime ya `:<boşluk>` ile ya da `<boşluk>#` ayraçları ile bir metine bağlanmalı (bu [git trailer convention](https://git-scm.com/docs/git-interpret-trailers)'dan ilham almıştır).
|
||||
9. Alt metin anahtar kelimesi boşluk karakteri yerine `-` kullanmalı. Örneğin `Acked-by` (bu alt metnin çok paragraflı mesaj metinlerinden ayırılmasına yardımcı olur). Buna sadece istisna olarak sadece `BREAKING CHANGE` kalıbını anahtar kelime olarak kullanımına izin verilmiştir.
|
||||
10. Alt metin birden fazla boşluk ve satır içerEBİLİR, ve bir sonraki geçerli anahtar kelimeye ulaştığında bitmiş demektir.
|
||||
11. Yıkıcı değişiklikler ya tip/kapsam içinde ya da alt metin olarak belirtilMELİDİR.
|
||||
12. Eğer alt metin içinde belirtiliyorsa, yıkıcı değişiklik büyük harflerle BREAKING CHANGE ile başlaMALI, iki nokta işareti, boşluk ve açıklama ile devam etMELİDİR. Örneğin *BREAKING CHANGE: environment variables now take precedence over config files* gibi.
|
||||
13. Eğer tip/kapsam içinde belirtiliyorsa, yıkıcı değişiklikler `:` işaretinden önce `!` ile belirtilmelidir. Eğer `!` kullanılırsa altmetinde `BREAKING CHANGE:` kullanılMAYABİLİR ve commit açıklaması yıkıcı değişikliği tanımlamak için kullanılABİLİR.
|
||||
14. `feat` ve `fix` dışındaki tipler de kullanılABİLİR. Örneğin *docs: updated ref docs.*.
|
||||
15. Uygulamaya çalışanlar Conventional Commits'i oluştura kalıpları büyük/küçük harf duyarlı düşünMEMELİ. Buna tek istisna BREAKING CHANGE kalıbıdır çünkü her zaman büyük harfle yazılMALIdır.
|
||||
2. `feat` tipi commit, uygulamaya ya da kütüphaneye yeni bir özellik ekliyorsa kullanılMALI.
|
||||
3. `fix` tipi commit, uygulamadaki bir hatayı düzeltiyorsa kullanılMALI.
|
||||
4. Tip bilgisinden sonra bir kapsam belirtilEBİLİR. Kapsam bilgisi parantez içerisinde kodun hangi bölümünün değiştiğini açıklayan bir isimden oluşMALI. Örneğin `fix(parser):`.
|
||||
5. Açıklama ön tip/kapsam bilgilerinden sonraki iki nokta ve boşluktan hemen sonra yazılMALIdır. Açıklama kısmı yapılan değişikliği anlatan kısa bir özettir. Örneğin *fix: array parsing issue when multiple spaces were contained in string*.
|
||||
6. Kısa açıklamadan sonra, kod değişiklikleri hakkında ek bağlamsal bilgiler sağlayan daha uzun bir commit mesajı metni yazılABİLİR. Mesaj metni açıklamadan sonra boş bir satırdan sonra başlaMALIDIR.
|
||||
7. Bir commitin mesaj metni serbest şekildedir ve boş bir satırla ayrılan herhangi bir sayıda paragraftan oluşABİLİR.
|
||||
8. Bir ya da birden fazla alt metin mesaj metninden bir boş satır sonra koyulABİLİR. Her alt metin bir anahtar kelime ile başlaMALI, anahtar kelime ya `:<boşluk>` ile ya da `<boşluk>#` ayraçları ile bir metine bağlanmalı (bu özellik [git trailer convention](https://git-scm.com/docs/git-interpret-trailers)'dan ilham alınmıştır).
|
||||
9. Alt metin anahtar kelimesi boşluk karakteri yerine `-` kullanmalı. Örneğin `Acked-by` (bu alt metnin çok paragraflı mesaj metinlerinden ayırılmasına yardımcı olur). Buna istisna olarak sadece `BREAKING CHANGE` kalıbının anahtar kelime olarak kullanımına izin verilmiştir.
|
||||
10. Alt metin birden fazla boşluk ve satır içerEBİLİR, ve bir sonraki geçerli anahtar kelimeye ulaştığında bitmiş olMALI.
|
||||
11. Köklü değişiklikler ya tip/kapsam içinde ya da alt metin olarak belirtilMELİDİR.
|
||||
12. Eğer alt metin içinde belirtiliyorsa, köklü değişiklik büyük harflerle BREAKING CHANGE ile başlaMALI, iki nokta işareti, boşluk ve açıklama ile devam etMELİDİR. Örneğin *BREAKING CHANGE: environment variables now take precedence over config files* gibi.
|
||||
13. Eğer tip/kapsam içinde belirtiliyorsa, köklü değişiklikler `:` işaretinden önce `!` ile belirtilmelidir. Eğer `!` kullanılırsa alt metinde `BREAKING CHANGE:` kullanılMAYABİLİR ve commit açıklaması köklü değişikliği tanımlamak için kullanılABİLİR.
|
||||
14. `feat` ve `fix` dışındaki tipler mesaj metninde tekrar kullanılABİLİR. Örneğin *docs: updated ref docs.*.
|
||||
15. Conventional Commits ile harmanlanmış kalıplar, geliştiriciler tarafından büyük/küçük harf duyarlı olarak düşünülMEMELİ. Buna tek istisna BREAKING CHANGE kalıbıdır çünkü her zaman büyük harfle yazılMALIdır.
|
||||
16. Alt metinde anahtar olarak kullanılırken BREAKING CHANGE BREAKING-CHANGE şeklinde yazılMALI.
|
||||
|
||||
## Neden Conventional Commits'e Uymalıyız
|
||||
|
||||
- CHANGELOG'ları otomatik olarak oluşturma.
|
||||
- Bir semantik version tümcesini otomatik olarak belirleme (commit işlemlerinin tiplerine göre).
|
||||
- Bir semantik versiyon geçişini otomatik olarak belirleme (commit işlemlerinin tiplerine göre).
|
||||
- Değişikliklerin doğasını ekip arkadaşlarına, kamuya ve diğer paydaşlara iletmek.
|
||||
- Derleme ve yayınlama işlemlerini tetikleme.
|
||||
- İnsanların daha yapılandırılmış bir commit geçmişini kendi kendilerine keşfetmelerine imkan vererek projelerinize katkıda bulunmalarını kolaylaştırmak.
|
||||
@ -138,47 +136,47 @@ Herhangi biri kullanılabilir, ancak tutarlı olmak en iyisidir.
|
||||
|
||||
Geri dönün ve mümkün olduğunca çok commit yapın. Conventional Commits'in avantajlarından biri, bizi daha organize commit ve PR yapmaya teşvik etmesidir.
|
||||
|
||||
### Bu, hızlı gelişimi ve hızlı döngüyü yapma cesaretini kırmıyor mu?
|
||||
### Bu, hızlı geliştirme ve hızlı ilerleme cesaretini kırmıyor mu?
|
||||
|
||||
Dağınıklık içinde hızlı bir şekilde hareket etmeyi önler. Uzun vadede çeşitli katkıda bulunanlar ile birden fazla projede daha hızlı bir şekilde ilerlemenize yardımcı olur.
|
||||
Bu, dağınıklık içinde hızlı bir şekilde hareket etmeyi önler. Uzun vadede, çeşitli katkıda bulunanlar ile birden fazla projede daha hızlı bir şekilde ilerlemenize yardımcı olur.
|
||||
|
||||
### Conventional Commits, geliştiricileri sağlanan tipleri düşünecekleri için yaptıkları taahhütlerin tipini sınırlamaya yönlendirebilir mi?
|
||||
### Conventional Commits, sağlanan tipleri düşünecekleri için geliştiricilerin yaptıkları commit'lerin tipini sınırlamaya yönlendirebilir mi?
|
||||
|
||||
Conventional Commits, hata düzeltmeleri gibi belirli commit tiplerinden daha fazlasını yapmamızı teşvik eder. Bunun dışında, Conventional Commits'in esnekliği, ekibinizin kendi tiplerini bulmasına ve zamanla bu tipleri değiştirmesine olanak tanır.
|
||||
Conventional Commits, hata düzeltmeleri(fixes) gibi kesin olan commit tiplerinden daha fazla yapmamızı teşvik eder. Bunun dışında, Conventional Commits'in esnekliği, ekibinizin kendi tiplerini bulmasına ve zamanla bu tipleri değiştirmesine olanak tanır.
|
||||
|
||||
### Bunun SemVer ile ilişkisi nedir?
|
||||
|
||||
`fix` tipi commit `PATCH` sürüm olarak yayınlanabilir. `feat` tipinde commit `MINOR` sürüm olarak yayınlanabilir. `BREAKING CHANGE` içeren commit, tipi ne olursa olsun `MAJOR` olarak yayınlanabilir.
|
||||
`fix` tipi commit `PATCH` sürüm olarak tercüme edilebilir. `feat` tipinde commit `MINOR` sürüm olarak tercüme edilebilir. `BREAKING CHANGE` içeren commit, tipi ne olursa olsun `MAJOR` olarak tercüme edilebilir.
|
||||
|
||||
### Conventional Commits sözleşmesine yaptığım eklentiyi nasıl sürümlendirmeliyim, Örneğin `@jameswomack/conventional-commit-spec` şeklinde mi?
|
||||
### Conventional Commits yönergesinde yaptığım eklentiyi nasıl sürümlendirmeliyim, Örneğin `@jameswomack/conventional-commit-spec` şeklinde mi?
|
||||
|
||||
Bu sözleşmeye ait kendi uzantılarınızı yayınlamak için SemVer kullanmanızı öneririz (ve bu uzantıları oluşturmanızı teşvik ediyoruz!).
|
||||
Bu yönergeye ait kendi uzantılarınızı yayınlamak için SemVer kullanmanızı öneririz (ayrıca bu uzantıları oluşturmanızı destekliyoruz!).
|
||||
|
||||
### Yanlışlıkla yanlış commit tipi kullanırsam ne yapmalıyım?
|
||||
### Yanlışlıkla yanlış bir commit tipi kullanırsam ne yapmalıyım?
|
||||
|
||||
#### Sözleşemede olan ancak doğru olmayan bir tip kullandığınızda, örneğin `feat` yerine `fix`
|
||||
#### Yönergede olan ancak doğru olmayan bir tip kullandığınızda, örneğin `feat` yerine `fix`
|
||||
|
||||
Hatayı birleştirmeden veya yayınlamadan önce, commit geçmişini düzenlemek için `git rebase -i` kullanmanızı öneririz. Yayınlandıktan sonra temizleme, kullandığınız araç ve işlemlere göre farklı olacaktır.
|
||||
Hatayı birleştirmeden veya yayınlamadan önce, commit geçmişini düzenlemek için `git rebase -i` kullanmanızı öneririz. Yayınlandıktan sonra temizleme ise, kullandığınız araç ve işlemlere göre farklı olacaktır.
|
||||
|
||||
#### Şözleşmede *olmayan* bir tür kullandığınızda, örneğin `feat` yerine `feet`
|
||||
#### Yönergede *olmayan* bir tür kullandığınızda, örneğin `feat` yerine `feet`
|
||||
|
||||
En kötü durumda, Conventional Commits şartnamesine uymayan bir commit tipi dünyanın sonu değildir. Bu sadece commit'in sözleşmeye dayalı araçlar tarafından kaçırılacağı anlamına gelir.
|
||||
En kötü durumda bile, Conventional Commits yönergesine uymayan bir commit tipi dünyanın sonu değildir. Bu sadece commit'in yönergeye dayalı araçlar tarafından, commit'in kaçırılacağı anlamına gelir.
|
||||
|
||||
### Tüm proje katılımcılarının Conventional Commits şartnamesini kullanması gerekiyor mu?
|
||||
### Tüm projeye katkıda bulunanlar Conventional Commits yönergesini kullanması gerekiyor mu?
|
||||
|
||||
Hayır! Git'te squash tabanlı bir iş akışı kullanırsanız, proje yürütücüleri birleştirme sırasında commit mesajlarını temizleyebilir; bu da dışardan katkı yapanlara iş yükü eklemez.
|
||||
Bunun için yaygın bir iş akışı, git sisteminizin otomatik olarak bir PR isteğinden commit mesajlarını ayırmasını ve isteği kabul edecek kişinin için birleştirme için uygun git commit mesajını girmesi için bir form sunmasını sağlamaktır.
|
||||
Bunun için yaygın bir iş akışı olarak, git sisteminizin otomatik olarak bir PR isteğinden commit mesajlarını ayırmasını ve isteği kabul edecek kişinin birleştirme sırasında uygun git commit mesajını girmesi için bir form sunmasını sağlamaktır.
|
||||
|
||||
### Conventional Commits geri dönen commit'leri nasıl ele alır?
|
||||
### Conventional Commits geri döndürülen commit'leri nasıl ele alır?
|
||||
|
||||
Eklenen bir kodu geri almak karmaşık olabilir: birden fazla işi geri mi alıyorsunuz? Bir özelliği geri alıyorsanız, bir sonraki sürüm belki de bir yama mı olmalı?
|
||||
Eklenen bir kodu geri almak karmaşık olabilir: birden fazla commit'i mi geri alıyorsunuz? Bir özelliği geri alıyorsanız, bir sonraki sürüm veya belkide bir yama mı olmalı?
|
||||
|
||||
Conventional Commits, geri döndürme davranışını tanımlamak için açık bir çaba göstermez. Bunun yerine bu işi geliştiricilere bırakıyoruz, geliştiriciler geri dönüşleri ele almak için kendi yollarını geliştirmek üzere *tiplerin* ve *alt metinlerin* esnekliğini kullanabilirler.
|
||||
|
||||
Bir öneri şöyle olabilir, `revert` tipini ve geri döndürülen commit'in SHA bilgisini başvuran bir alt metinde belirtmektir:
|
||||
|
||||
```
|
||||
revert: let us never again speak of the noodle incident
|
||||
revert: bir daha asla noodle olayından bahsetmeyelim
|
||||
|
||||
Refs: 676104e, a215868
|
||||
```
|
||||
|
||||
@ -76,7 +76,7 @@ BREAKING CHANGE: `extends` key in config file is now used for extending other co
|
||||
feat!: send an email to the customer when a product is shipped
|
||||
```
|
||||
|
||||
### 包含了范围和破坏性变更 `!` 的提交說明
|
||||
### 包含了范围和破坏性变更 `!` 的提交说明
|
||||
```
|
||||
feat(api)!: send an email to the customer when a product is shipped
|
||||
```
|
||||
|
||||
@ -66,6 +66,7 @@
|
||||
padding: 12px 16px;
|
||||
border-radius: 50px;
|
||||
text-decoration: none;
|
||||
line-height: 1.5;
|
||||
color: $welcome-action-color;
|
||||
border: 1px solid $welcome-action-color;
|
||||
margin-right: $gap-md;
|
||||
|
||||
Loading…
Reference in New Issue
Block a user