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:
Vilas Sonje
GitHub
commit
1e25c30c09
@ -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>
|
||||
18
config.yaml
18
config.yaml
@ -449,3 +449,21 @@ languages:
|
||||
current: v1.0.0
|
||||
list:
|
||||
- v1.0.0
|
||||
|
||||
ar:
|
||||
weight: 24
|
||||
languageName: "العربية"
|
||||
title: Conventional Commits
|
||||
description: إضافة معنى قابل للقراءة من قبل الإنسان والآلة إلى رسائل الـ commit.
|
||||
actions:
|
||||
- label: الملخص
|
||||
url: '# الملخص'
|
||||
- label: المواصفات
|
||||
url: '# المواصفات'
|
||||
- label: شارك في المشروع
|
||||
url: 'https://github.com/conventional-commits/conventionalcommits.org'
|
||||
versions:
|
||||
current: v1.0.0
|
||||
list:
|
||||
- v1.0.0
|
||||
rtl: true
|
||||
@ -57,10 +57,12 @@ 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?
|
||||
|
||||
|
||||
@ -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` をおすすめします。
|
||||
|
||||
@ -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)。
|
||||
|
||||
178
content/v1.0.0/index.ar.md
Normal file
178
content/v1.0.0/index.ar.md
Normal file
@ -0,0 +1,178 @@
|
||||
---
|
||||
draft: false
|
||||
aliases: ["/ar/"]
|
||||
---
|
||||
|
||||
# Conventional Commits 1.0.0
|
||||
|
||||
## الملخص
|
||||
|
||||
مواصفة Conventional Commits هي اتفاقية خفيفة الوزن تتعلق برسائل الالتزام (commit messages).
|
||||
توفر مجموعة سهلة من القواعد لإنشاء تاريخ التزام واضح؛ مما يسهل كتابة أدوات آلية تستند إليها.
|
||||
تتوافق هذه الاتفاقية مع [SemVer](http://semver.org)، بوصف الميزات، الإصلاحات، والتغييرات الجوهرية التي تتم في رسائل الالتزام.
|
||||
|
||||
يجب أن تكون رسالة الالتزام على النحو التالي:
|
||||
|
||||
---
|
||||
|
||||
```
|
||||
<type>[optional scope]: <description>
|
||||
|
||||
[optional body]
|
||||
|
||||
[optional footer(s)]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
<br /> تحتوي رسالة الالتزام على العناصر الهيكلية التالية، للتواصل مع مستخدمي مكتبتك:
|
||||
|
||||
1. **fix:** الالتزام من نوع `fix` يقوم بإصلاح خطأ في قاعدة الكود (يتوافق مع [`PATCH`](http://semver.org/#summary) في الإصدار الدلالي).
|
||||
2. **feat:** الالتزام من نوع `feat` يقدم ميزة جديدة إلى قاعدة الكود (يتوافق مع [`MINOR`](http://semver.org/#summary) في الإصدار الدلالي).
|
||||
3. **BREAKING CHANGE:** الالتزام الذي يحتوي على footer `BREAKING CHANGE:` أو إضافة `!` بعد النوع/النطاق، يُدخل تغييراً كبيراً على API (يتوافق مع [`MAJOR`](http://semver.org/#summary) في الإصدار الدلالي).
|
||||
يمكن أن يكون التغيير الجذري جزءًا من أي نوع من الالتزامات.
|
||||
4. الأنواع الأخرى غير `fix:` و `feat:` مسموحة، مثل [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (استنادًا إلى [اتفاقية Angular](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) التي توصي بـ `build:`, `chore:`, `ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:` وغيرها.
|
||||
5. يُمكن إضافة footers أخرى غير `BREAKING CHANGE: <description>` والتي تتبع اتفاقية مشابهة لـ
|
||||
[صيغة trail git](https://git-scm.com/docs/git-interpret-trailers).
|
||||
|
||||
الأنواع الإضافية ليست مفروضة من قبل مواصفة Conventional Commits، وليس لها تأثير ضمني في الإصدار الدلالي (إلا إذا تضمنت تغييرًا جذريًا).
|
||||
<br /><br />
|
||||
يمكن توفير نطاق (scope) لنوع الالتزام، لتوفير معلومات سياقية إضافية ويكون محصورًا بين قوسين، مثل `feat(parser): add ability to parse arrays`.
|
||||
|
||||
## أمثلة
|
||||
|
||||
### رسالة التزام مع وصف و footer لتغيير جذري
|
||||
```
|
||||
feat: allow provided config object to extend other configs
|
||||
|
||||
BREAKING CHANGE: `extends` key in config file is now used for extending other config files
|
||||
```
|
||||
|
||||
### رسالة التزام تحتوي على `!` للفت الانتباه إلى التغيير الجذري
|
||||
```
|
||||
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
|
||||
```
|
||||
|
||||
### رسالة التزام تحتوي على `!` و footer لتغيير جذري
|
||||
```
|
||||
chore!: drop support for Node 6
|
||||
|
||||
BREAKING CHANGE: use JavaScript features not available in Node 6.
|
||||
```
|
||||
|
||||
### رسالة التزام بدون body
|
||||
```
|
||||
docs: correct spelling of CHANGELOG
|
||||
```
|
||||
|
||||
### رسالة التزام تحتوي على نطاق
|
||||
```
|
||||
feat(lang): add Polish language
|
||||
```
|
||||
|
||||
### رسالة التزام تحتوي على body متعدد الفقرات و footers متعددة
|
||||
```
|
||||
fix: prevent racing of requests
|
||||
|
||||
Introduce a request id and a reference to latest request. Dismiss
|
||||
incoming responses other than from latest request.
|
||||
|
||||
Remove timeouts which were used to mitigate the racing issue but are
|
||||
obsolete now.
|
||||
|
||||
Reviewed-by: Z
|
||||
Refs: #123
|
||||
```
|
||||
|
||||
## المواصفات
|
||||
|
||||
الكلمات الرئيسية "MUST"، "MUST NOT"، "REQUIRED"، "SHALL"، "SHALL NOT"، "SHOULD"، "SHOULD NOT"، "RECOMMENDED"، "MAY"، و "OPTIONAL" في هذا المستند يجب تفسيرها كما هو موضح في [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
|
||||
|
||||
1. يجب أن تسبق الالتزامات بنوع، يتكون من اسم مثل `feat`، `fix`، وما إلى ذلك، متبوعًا بـ scope اختياري، و `!` اختياري، والنقطتين الإلزاميتين والمسافة.
|
||||
2. يجب استخدام النوع `feat` عندما يضيف الالتزام ميزة جديدة لتطبيقك أو مكتبتك.
|
||||
3. يجب استخدام النوع `fix` عندما يمثل الالتزام إصلاحًا لخطأ في تطبيقك.
|
||||
4. يمكن توفير scope بعد النوع. يجب أن يتكون scope من اسم يصف جزءًا من قاعدة الكود محاطًا بأقواس، مثل `fix(parser):`.
|
||||
5. يجب أن يتبع الوصف مباشرة النقطتين والمسافة بعد النوع/النطاق. الوصف هو ملخص قصير للتغييرات في الكود، مثل _fix: array parsing issue when multiple spaces were contained in string_.
|
||||
6. يمكن توفير body أطول بعد الوصف القصير، لتوفير معلومات سياقية إضافية حول تغييرات الكود. يجب أن يبدأ body بسطر فارغ بعد الوصف.
|
||||
7. يمكن أن يتكون body من أي عدد من الفقرات مفصولة بأسطر جديدة.
|
||||
8. يمكن توفير واحد أو أكثر من footers بعد سطر فارغ بعد body. يجب أن يتكون كل footer من رمز (token) متبوعًا إما بـ `:<space>` أو `<space>#` متبوعًا بقيمة نصية (مستوحى من
|
||||
[اتفاقية trailer الخاصة بـ git](https://git-scm.com/docs/git-interpret-trailers)).
|
||||
9. يجب أن يستخدم token الخاص بـ footer `-` بدلاً من أحرف المسافات، مثل `Acked-by` (يساعد هذا في التفريق بين قسم footers و body متعدد الفقرات). يتم استثناء `BREAKING CHANGE`، الذي يمكن أيضًا استخدامه كـ token.
|
||||
10. قد تحتوي قيمة footer على مسافات وأسطر جديدة، ويجب أن يتوقف التحليل عندما يتم ملاحظة زوج جديد من token/الفاصل الصحيح.
|
||||
11. يجب الإشارة إلى التغييرات الجذرية في بادئة النوع/النطاق للالتزام، أو كمدخل في footer.
|
||||
12. إذا تم تضمينها كـ footer، يجب أن تتكون التغييرات الجذرية من النص بأحرف كبيرة BREAKING CHANGE، متبوعًا بنقطتين ومسافة ووصف، مثل _BREAKING CHANGE: environment variables now take precedence over config files_.
|
||||
13. إذا تم تضمينها في بادئة النوع/النطاق، يجب الإشارة إلى التغييرات الجذرية بواسطة `!` مباشرة قبل `:`. إذا تم استخدام `!`، يمكن حذف `BREAKING CHANGE:` من قسم footer، ويجب استخدام وصف الالتزام لوصف التغيير الجذري.
|
||||
14. يمكن استخدام أنواع أخرى غير `feat` و `fix` في رسائل الالتزام، مثل _docs: update ref docs_.
|
||||
15. لا يجب التعامل مع وحدات المعلومات التي تتكون منها Conventional Commits على أنها حساسة لحالة الأحرف من قبل المنفذين، باستثناء BREAKING CHANGE الذي يجب أن يكون بأحرف كبيرة.
|
||||
16. يجب أن تكون BREAKING-CHANGE مرادفة لـ BREAKING CHANGE عند استخدامها كـ token في footer.
|
||||
|
||||
## لماذا نستخدم Conventional Commits؟
|
||||
|
||||
* إنشاء CHANGELOGs تلقائيًا.
|
||||
* تحديد رفع الإصدار الدلالي تلقائيًا (استنادًا إلى أنواع الالتزامات المضافة).
|
||||
* التواصل بطبيعة التغييرات إلى الزملاء والجمهور وغيرهم من أصحاب المصلحة.
|
||||
* تشغيل عمليات البناء والنشر.
|
||||
* تسهيل مساهمة الأشخاص في مشاريعك من خلال السماح لهم باستكشاف تاريخ الالتزامات بشكل منظم.
|
||||
|
||||
## الأسئلة المتكررة
|
||||
|
||||
### كيف أتعامل مع رسائل الالتزام في مرحلة التطوير الأولية؟
|
||||
|
||||
نوصي بأن تتعامل كما لو أنك أصدرت المنتج بالفعل. عادةً ما يكون هناك *شخص ما*، حتى لو كانوا مطورين آخرين، يستخدمون البرنامج. سيرغبون في معرفة ما الذي تم إصلاحه وما هي التغييرات الكبيرة.
|
||||
|
||||
### هل تكون الأنواع في عنوان الالتزام بأحرف كبيرة أو صغيرة؟
|
||||
|
||||
يمكن استخدام أي حالة، ولكن من الأفضل أن تكون متسقة.
|
||||
|
||||
### ماذا أفعل إذا كان الالتزام يتوافق مع أكثر من نوع من الأنواع؟
|
||||
|
||||
يفضل أن تقوم بعمل عدة التزامات كلما كان ذلك ممكنًا. جزء من فائدة Conventional Commits هو دفعنا لإجراء التزامات وتنظيم أكثر.
|
||||
|
||||
### ألا يشجع ذلك على الحد من سرعة التطوير والتكرار السريع؟
|
||||
|
||||
إنه يشجع على عدم التحرك بسرعة بطريقة غير منظمة. يساعدك على التحرك بسرعة على المدى الطويل عبر مشاريع متعددة مع مساهمين متنوعين.
|
||||
|
||||
### هل قد تؤدي "Conventional Commits" إلى تقييد المطورين في نوع الـ commits التي يقومون بها لأنهم سيفكرون في الأنواع المقدمة؟
|
||||
|
||||
تشجع "Conventional Commits" المطورين على القيام بمزيد من أنواع الـ commits مثل الإصلاحات (fixes). بخلاف ذلك، فإن مرونة "Conventional Commits" تسمح لفريقك بتحديد أنواعهم الخاصة وتغيير تلك الأنواع مع مرور الوقت.
|
||||
|
||||
### كيف يرتبط هذا بـ SemVer؟
|
||||
|
||||
يجب أن تترجم الـ commits من النوع `fix` إلى إصدارات `PATCH`. ويجب أن تترجم الـ commits من النوع `feat` إلى إصدارات `MINOR`. الـ commits التي تحتوي على `BREAKING CHANGE`، بغض النظر عن النوع، يجب أن تترجم إلى إصدارات `MAJOR`.
|
||||
|
||||
### كيف يجب أن أقوم بتحديد الإصدارات لامتداداتي لمواصفة "Conventional Commits"، مثل `@jameswomack/conventional-commit-spec`؟
|
||||
|
||||
نوصي باستخدام SemVer لإصدار امتداداتك الخاصة لهذه المواصفة (ونشجعك على تطوير هذه الامتدادات!).
|
||||
|
||||
### ماذا أفعل إذا استخدمت نوع commit خاطئ عن طريق الخطأ؟
|
||||
|
||||
#### عندما تستخدم نوعاً موجوداً في المواصفة ولكنه ليس النوع الصحيح، مثل `fix` بدلاً من `feat`
|
||||
|
||||
قبل الدمج أو إصدار الخطأ، نوصي باستخدام `git rebase -i` لتعديل تاريخ الـ commits. بعد الإصدار، تختلف عملية التصحيح اعتماداً على الأدوات والعمليات التي تستخدمها.
|
||||
|
||||
#### عندما تستخدم نوع commit غير موجود في المواصفة، مثل `feet` بدلاً من `feat`
|
||||
|
||||
في أسوأ الأحوال، إذا تم تمرير commit لا يتوافق مع مواصفة "Conventional Commits"، فليس هذا نهاية العالم. هذا يعني ببساطة أن هذا الـ commit لن يتم التعرف عليه بواسطة الأدوات التي تعتمد على هذه المواصفة.
|
||||
|
||||
### هل يحتاج جميع المساهمين في مشروعي إلى استخدام مواصفة "Conventional Commits"؟
|
||||
|
||||
لا! إذا كنت تستخدم أسلوب "squash" في Git، يمكن للمسؤولين الرئيسيين تنظيف رسائل الـ commits عند الدمج، دون إضافة عبء على المساهمين العرضيين. إحدى الأساليب الشائعة لذلك هي أن يقوم نظام git تلقائيًا بـ "squash" الـ commits من طلب السحب (pull request) ويعرض نموذجًا للمسؤول الرئيسي لإدخال رسالة git commit المناسبة للدمج.
|
||||
|
||||
### كيف تتعامل "Conventional Commits" مع الـ commits الخاصة بالتراجع (revert)؟
|
||||
|
||||
يمكن أن يكون التراجع عن الشيفرة معقداً: هل تقوم بالتراجع عن عدة commits؟ إذا كنت تتراجع عن ميزة (feature)، هل يجب أن يكون الإصدار التالي تصحيحاً (patch) بدلاً من ذلك؟
|
||||
|
||||
لا تبذل "Conventional Commits" جهداً صريحاً لتحديد سلوك التراجع. بدلاً من ذلك، نترك الأمر لمطوري الأدوات للاستفادة من مرونة الأنواع والتذييلات (_types_ و _footers_) لتطوير منطقهم في التعامل مع التراجعات.
|
||||
|
||||
أحد التوصيات هو استخدام نوع `revert`، وتذييل يشير إلى SHAs الخاصة بالـ commits التي يتم التراجع عنها:
|
||||
|
||||
```
|
||||
revert: لن نتحدث أبداً عن حادثة الـ noodle مرة أخرى
|
||||
|
||||
Refs: 676104e, a215868
|
||||
```
|
||||
@ -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
|
||||
```
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<html class="{{ if .Site.Language.Params.rtl }}rtl{{ end }}">
|
||||
{{- partial "head.html" . -}}
|
||||
<body class="conventional-commits--loading">
|
||||
{{- partial "header.html" . -}}
|
||||
|
||||
@ -9,7 +9,7 @@
|
||||
{{ end }}
|
||||
</div>
|
||||
{{ end }}
|
||||
<figure class="welcome__image">
|
||||
<figure class="welcome__image {{ if .Site.Language.Params.rtl }}rtl__image{{ end }}">
|
||||
<img src='{{default "/img/git-flow--welcome.png"}}'>
|
||||
</figure>
|
||||
</div>
|
||||
|
||||
@ -15,6 +15,12 @@ body {
|
||||
font: 16px Helvetica, sans-serif;
|
||||
}
|
||||
|
||||
// Apply RTL direction only if 'rtl' class is present
|
||||
html.rtl body, html.rtl .content {
|
||||
direction: rtl;
|
||||
text-align: right;
|
||||
}
|
||||
|
||||
.container {
|
||||
width: 100%;
|
||||
max-width: $desktop-width;
|
||||
|
||||
@ -74,10 +74,6 @@
|
||||
transition: background-color .3s ease, color .3s ease;
|
||||
min-width: fit-content;
|
||||
|
||||
&:last-child {
|
||||
margin-right: 0;
|
||||
}
|
||||
|
||||
&:hover {
|
||||
background-color: $welcome-action-color;
|
||||
color: get-color-accessible-for-background($welcome-action-color)
|
||||
@ -110,5 +106,11 @@
|
||||
max-height: 100%;
|
||||
}
|
||||
}
|
||||
|
||||
// Override for RTL layout if RTL is enabled
|
||||
.rtl__image {
|
||||
right: auto !important;
|
||||
left: 0;
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user