Showing preview only (690K chars total). Download the full file or copy to clipboard to get everything.
Repository: conventional-commits/conventionalcommits.org
Branch: master
Commit: 7d293dc59e88
Files: 121
Total size: 653.5 KB
Directory structure:
gitextract_w3upijgj/
├── .gitignore
├── .node-version
├── CODE_OF_CONDUCT.md
├── CONTRIBUTING.md
├── Dockerfile
├── Dockerfile.dev
├── LICENSE
├── Makefile
├── README.md
├── _redirects
├── archetypes/
│ ├── about.md
│ ├── next.md
│ ├── v1.0.0-beta.1.md
│ ├── v1.0.0-beta.2.md
│ ├── v1.0.0-beta.3.md
│ ├── v1.0.0-beta.md
│ └── v1.0.0.md
├── config.yaml
├── content/
│ ├── about/
│ │ └── index.md
│ ├── next/
│ │ └── index.md
│ ├── v1.0.0/
│ │ ├── index.ar.md
│ │ ├── index.be.md
│ │ ├── index.bn.md
│ │ ├── index.de.md
│ │ ├── index.es.md
│ │ ├── index.fr.md
│ │ ├── index.gr.md
│ │ ├── index.hi.md
│ │ ├── index.hy.md
│ │ ├── index.id.md
│ │ ├── index.it.md
│ │ ├── index.ja.md
│ │ ├── index.ko.md
│ │ ├── index.md
│ │ ├── index.ml.md
│ │ ├── index.nl.md
│ │ ├── index.pl.md
│ │ ├── index.pr.md
│ │ ├── index.pt-br.md
│ │ ├── index.ro.md
│ │ ├── index.ru.md
│ │ ├── index.si.md
│ │ ├── index.sr.md
│ │ ├── index.ta.md
│ │ ├── index.th.md
│ │ ├── index.tr.md
│ │ ├── index.uk.md
│ │ ├── index.uz.md
│ │ ├── index.zh-hans.md
│ │ └── index.zh-hant.md
│ ├── v1.0.0-beta/
│ │ ├── index.it.md
│ │ ├── index.md
│ │ ├── index.pl.md
│ │ └── index.zh-hans.md
│ ├── v1.0.0-beta.1/
│ │ ├── index.it.md
│ │ ├── index.md
│ │ ├── index.pl.md
│ │ └── index.zh-hans.md
│ ├── v1.0.0-beta.2/
│ │ ├── index.es.md
│ │ ├── index.fr.md
│ │ ├── index.it.md
│ │ ├── index.md
│ │ ├── index.pl.md
│ │ ├── index.ru.md
│ │ └── index.zh-hans.md
│ ├── v1.0.0-beta.3/
│ │ ├── index.es.md
│ │ ├── index.fr.md
│ │ ├── index.hy.md
│ │ ├── index.it.md
│ │ ├── index.md
│ │ ├── index.pt-br.md
│ │ ├── index.ru.md
│ │ └── index.zh-hans.md
│ └── v1.0.0-beta.4/
│ ├── index.fr.md
│ ├── index.hy.md
│ ├── index.id.md
│ ├── index.it.md
│ ├── index.ja.md
│ ├── index.ko.md
│ ├── index.md
│ ├── index.pt-br.md
│ ├── index.ru.md
│ ├── index.zh-hans.md
│ └── index.zh-hant.md
├── data/
│ └── .gitkeep
├── docker-compose.yml
├── layouts/
│ └── .gitkeep
├── static/
│ └── .gitkeep
└── themes/
└── conventional-commits/
├── .editorconfig
├── .gitignore
├── LICENSE
├── README.md
├── archetypes/
│ └── default.md
├── layouts/
│ ├── 404.html
│ ├── _default/
│ │ └── single.html
│ ├── about/
│ │ └── single.html
│ ├── partials/
│ │ ├── footer.html
│ │ ├── head.html
│ │ ├── header.html
│ │ ├── mini_welcome.html
│ │ ├── scripts.html
│ │ ├── svg-github.html
│ │ └── welcome.html
│ └── shortcodes/
│ └── banner-image.html
├── package.json
├── static/
│ ├── css/
│ │ └── scss/
│ │ ├── abstracts/
│ │ │ ├── _functions.scss
│ │ │ ├── _mixins.scss
│ │ │ ├── _variables.scss
│ │ │ └── index.scss
│ │ ├── base/
│ │ │ └── _base.scss
│ │ ├── components/
│ │ │ ├── _banner-image.scss
│ │ │ └── _dropdown.scss
│ │ ├── layout/
│ │ │ ├── _footer.scss
│ │ │ ├── _header.scss
│ │ │ └── _welcome.scss
│ │ ├── style.scss
│ │ ├── themes/
│ │ │ ├── _conventional-commits.scss
│ │ │ └── _markdown.scss
│ │ └── vendors/
│ │ └── github-markdown-css.scss
│ └── js/
│ └── index.js
└── theme.toml
================================================
FILE CONTENTS
================================================
================================================
FILE: .gitignore
================================================
public/
.idea/
================================================
FILE: .node-version
================================================
19.0.0
================================================
FILE: CODE_OF_CONDUCT.md
================================================
# Contributor Covenant Code of Conduct
## Our Pledge
In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
## Our Standards
Examples of behavior that contributes to creating a positive environment include:
* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery and unwelcome sexual attention or advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a professional setting
## Our Responsibilities
Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
## Scope
This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at bencoe@gmail.com or damianopetrungaro@gmail.com. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
[homepage]: http://contributor-covenant.org
[version]: http://contributor-covenant.org/version/1/4/
================================================
FILE: CONTRIBUTING.md
================================================
# How to Contribute
The contribution guideline is derived from the SlimPHP, Istanbul Code Coverage and Ruby contribution guideline
## Contributor Behavior
Be kind to one another. We're striving to make Conventional Commits an inclusive environment that's great for first time open-source contributors.
tldr; we value constructive community interaction, over technical acumen.
## Pull Requests
Conventional Commits use the [GitHub flow](https://guides.github.com/introduction/flow/) as main versioning workflow
1. Fork the Conventional Commits repository
2. Create a new branch for each feature, fix or improvement
3. Send a pull request from each feature branch to the **master** branch
It is very important to separate new features or improvements into separate feature branches, and to send a
pull request for each branch.
This allow us to review and pull in new features or improvements individually.
## Style Guide
All pull requests SHOULD adhere to the [Conventional Commits specification](https://conventionalcommits.org/)
## License
You must agree that your patch will be licensed under the Conventional Commit License, and when we change the license we will assume that you agreed with the change unless you object to the changes in time.
================================================
FILE: Dockerfile
================================================
FROM node:19.0.0-alpine
WORKDIR /src/
COPY ./themes/conventional-commits /src/
RUN apk add make
RUN npm install
RUN npm run build
FROM jguyomard/hugo-builder:latest
COPY ./ /src/
COPY --from=0 /src/ /src/themes/conventional-commits/
RUN hugo
FROM nginx:stable
COPY --from=1 /src/public/ /usr/share/nginx/html/
EXPOSE 80
================================================
FILE: Dockerfile.dev
================================================
FROM jguyomard/hugo-builder:latest
FROM node:19.0.0-alpine
WORKDIR /src/
COPY --from=0 /usr/local/bin/hugo /usr/local/bin/hugo
COPY ./ /src/
RUN apk add make
ENTRYPOINT make all-dev
EXPOSE 1313
================================================
FILE: LICENSE
================================================
MIT License
Copyright (c) 2018 Conventional Changelog
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
================================================
FILE: Makefile
================================================
all: compile-assets compile-site
all-dev: compile-assets-dev serve-site-dev
compile-site:
echo "Generating static website"
hugo
echo "Website generated"
serve-site-dev:
echo "Serving website"
hugo serve --bind=0.0.0.0
compile-assets:
echo "Compiling assets"
cd themes/conventional-commits && npm install && npm run build
echo "Assets compiled"
compile-assets-dev:
echo "Compiling assets"
cd themes/conventional-commits && npm install && npm run start &
================================================
FILE: README.md
================================================
# ConventionalCommits.org
[](https://conventionalcommits.org)
This repo is the home of the [Conventional Commits specification](https://www.conventionalcommits.org/).
## Repo Layout
We use [HUGO](https://gohugo.io/) as static site generator, so we use the [directory structure](https://gohugo.io/getting-started/directory-structure/) HUGO proposes.
#### Our implementation
* `./content`: contains all the versions of the specification.
* `./content/next/`: contains the version of the specification (where all the changes SHOULD be made).
* `./content/**/index.[lang].md`: contains the content of the specification, if a language is specified it's a translation.
## Contributing
We'd love your help refining the language of this specification,
fixing typos, or adding more translations. Please don't hesitate
to send a pull request.
### Adding a translation
1. Create a new file in `./content/version/index.[lang].md` using the hugo command `hugo new [version]/index.[lang].md`.
1. Ensure all files have the appropriate fields required (see others as an example)..
1. Add the language to the `config.yaml` file (see others as an example).
### Running project locally
There's a docker-compose.yml file ready that will help you to check if the website looks good!
To run it make sure you have [docker-compose installed](https://docs.docker.com/compose/install/#install-compose) on your machine and just use the command `docker-compose up` to make it run locally.
Once the website will be compiled, you can see the website visiting `http://localhost:1313`
## Badges!
Tell your users that you use the Conventional Commits specification:
```markdown
[](https://conventionalcommits.org)
```
## Thank you
To **[Lorenzo D'Ianni](https://github.com/lorenzodianni)** for the great effort creating the CSS and the HTML for the new UI.
To **[Netlify](https://www.netlify.com/)** to host our project, giving us a lot of [amazing built in functionality](https://www.netlify.com/features/) for free.
To **[semver.org](https://github.com/mojombo/semver.org)**: we used [semver.org](https://github.com/mojombo/semver.org) as a blueprint for
the structure of this specification and the first version of the website.
================================================
FILE: _redirects
================================================
/ /en/v1.0.0/
================================================
FILE: archetypes/about.md
================================================
---
type: about
draft: true
---
================================================
FILE: archetypes/next.md
================================================
---
draft: true
---
================================================
FILE: archetypes/v1.0.0-beta.1.md
================================================
---
draft: false
---
================================================
FILE: archetypes/v1.0.0-beta.2.md
================================================
---
draft: false
---
================================================
FILE: archetypes/v1.0.0-beta.3.md
================================================
---
draft: false
---
================================================
FILE: archetypes/v1.0.0-beta.md
================================================
---
draft: false
---
================================================
FILE: archetypes/v1.0.0.md
================================================
---
draft: false
---
================================================
FILE: config.yaml
================================================
baseURL: '/'
languageCode: en-us
theme: conventional-commits
defaultContentLanguageInSubdir: true
defaultContentLanguage: "en"
# Global parameters
params:
license:
title: License
action:
label: Creative Commons - CC BY 3.0
url: 'https://creativecommons.org/licenses/by/3.0/'
footer:
logos:
- name: github
url: 'https://github.com/conventional-commits/conventionalcommits.org'
# Languages parameters
languages:
en:
weight: 1
languageName: "English"
title: Conventional Commits
description: A specification for adding human and machine readable meaning to commit messages
actions:
- label: Quick Summary
url: '#summary'
- label: Full Specification
url: '#specification'
- label: Contribute
url: 'https://github.com/conventional-commits/conventionalcommits.org'
versions:
current: v1.0.0
list:
- v1.0.0
- v1.0.0-beta.4
- v1.0.0-beta.3
- v1.0.0-beta.2
- v1.0.0-beta.1
- v1.0.0-beta
it:
weight: 2
languageName: "Italian"
title: Commit Convenzionali
description: Una specifica per aggiungere un significato leggibile da umani e macchine ai messaggi dei commit
actions:
- label: Riepilogo
url: '#riepilogo'
- label: Leggi la specifica
url: '#specifica'
- label: GitHub
url: 'https://github.com/conventional-commits/conventionalcommits.org'
versions:
current: v1.0.0
list:
- v1.0.0
- v1.0.0-beta.4
- v1.0.0-beta.3
- v1.0.0-beta.2
- v1.0.0-beta.1
- v1.0.0-beta
pl:
weight: 3
languageName: "Polish"
title: Conventional Commits
description: Specyfikacja, nadająca czytelność commitom zarówno dla ludzi, jak i maszyn
actions:
- label: Przeczytaj specyfikację
url: '#specyfikacja'
- label: GitHub
url: 'https://github.com/conventional-commits/conventionalcommits.org'
versions:
current: v1.0.0
list:
- v1.0.0
- v1.0.0-beta.2
- v1.0.0-beta.1
- v1.0.0-beta
# zh-cn/zh-tw/zh-chs are legacy
# zh-hans specification usage from IETF language tag
# check https://www.ietf.org/rfc/rfc4646.txt
zh-hans:
weight: 4
languageName: "简体中文"
title: 约定式提交
description: 一种用于给提交信息增加人机可读含义的规范
actions:
- label: 阅读规范
url: '#约定式提交规范'
- label: GitHub
url: 'https://github.com/conventional-commits/conventionalcommits.org'
versions:
current: v1.0.0
list:
- v1.0.0
- v1.0.0-beta.4
- v1.0.0-beta.3
- v1.0.0-beta.2
- v1.0.0-beta.1
- v1.0.0-beta
zh-hant:
weight: 5
languageName: "繁體中文"
title: 慣例式提交
description: 一種用於增加提交說明之人機可讀性意義的規範
actions:
- label: 概述
url: '#概述'
- label: 完整規範
url: '#規範'
- label: 貢獻
url: 'https://github.com/conventional-commits/conventionalcommits.org'
versions:
current: v1.0.0
list:
- v1.0.0
- v1.0.0-beta.4
es:
weight: 6
languageName: "Spanish"
title: Commits Convencionales
description: Especificación para dar significado a los mensajes de los commits haciéndolos legibles para máquinas y humanos
actions:
- label: Lee la especificación
url: '#especificación'
- label: GitHub
url: 'https://github.com/conventional-commits/conventionalcommits.org'
versions:
current: v1.0.0-beta.3
list:
- v1.0.0-beta.3
- v1.0.0-beta.2
ru:
weight: 7
languageName: "Русский"
title: Соглашение о коммитах
description: Простое соглашение о том, как нужно писать сообщения коммитов
actions:
- label: Главное
url: '#главное'
- label: Спецификация
url: '#спецификация'
- label: GitHub
url: 'https://github.com/conventional-commits/conventionalcommits.org'
versions:
current: v1.0.0
list:
- v1.0.0
- v1.0.0-beta.4
- v1.0.0-beta.3
- v1.0.0-beta.2
ja:
weight: 8
languageName: "日本語"
title: Conventional Commits
description: 人間と機械が読みやすく、意味のあるコミットメッセージにするための仕様
actions:
- label: 簡単なまとめ
url: '#概要'
- label: すべての仕様
url: '#仕様'
- label: GitHub
url: 'https://github.com/conventional-commits/conventionalcommits.org'
versions:
current: v1.0.0
list:
- v1.0.0
- v1.0.0-beta.4
fr:
weight: 9
languageName: "Français"
title: Commits Conventionnels
description: Une spécification qui permet une signification lisible pour l'humain et pour la machine dans les messages des commits
actions:
- label: Spécification complète
url: '#spécification'
- label: GitHub
url: 'https://github.com/conventional-commits/conventionalcommits.org'
versions:
current: v1.0.0
list:
- v1.0.0
- v1.0.0-beta.2
hi:
weight: 10
languageName: "हिन्दी"
title: पारंपरिक कमिट (Conventional Commits)
description: कमिट संदेशों में मानव और मशीन दोनों के लिए अर्थ जोड़ने की एक विशिष्टता
actions:
- label: सारांश
url: '#summary'
- label: पूरी विशिष्टता
url: '#specification'
- label: GitHub
url: 'https://github.com/conventional-commits/conventionalcommits.org'
versions:
current: v1.0.0
list:
- v1.0.0
ko:
weight: 10
languageName: "한국어"
title: Conventional Commits
description: 커밋 메시지에 사용자와 기계 모두가 이해할 수 있는 의미를 부여하기 위한 스펙
actions:
- label: 요약
url: '#개요'
- label: 전체 스펙
url: '#규격'
- label: Github
url: 'https://github.com/conventional-commits/conventionalcommits.org'
versions:
current: v1.0.0-beta.4
list:
- v1.0.0-beta.4
pt-br:
weight: 11
languageName: "Português Brasileiro"
title: Conventional Commits
description: Uma especificação para dar um significado legível às mensagens de commit para humanos e máquinas
actions:
- label: Resumo
url: '#resumo'
- label: Especificação Completa
url: '#especificação'
- label: GitHub
url: 'https://github.com/conventional-commits/conventionalcommits.org'
versions:
current: v1.0.0
list:
- v1.0.0
- v1.0.0-beta.4
- v1.0.0-beta.3
id:
weight: 12
languageName: "Indonesia"
title: Komit Konvensional
description: Spesifikasi untuk menambahkan makna yang dapat dibaca manusia dan mesin untuk pesan komit
actions:
- label: Ringkasan
url: '#ringkasan'
- label: Spesifikasi
url: '#spesifikasi'
- label: GitHub
url: 'https://github.com/conventional-commits/conventionalcommits.org'
versions:
current: v1.0.0
list:
- v1.0.0
- v1.0.0-beta.4
- v1.0.0
hy:
weight: 13
languageName: "Հայերեն"
title: Համաձայնեցված «Commit»֊ներ
description: Սպեցիֆիկացիա, որը ընթեռնելի է դարձնում «commit» մեսիջները մեքենաների և մարդկանց համար
actions:
- label: Համառոտագիր
url: '#համառոտագիր'
- label: Սպեցիֆիկացիա
url: '#սպեցիֆիկացիա'
- label: GitHub
url: 'https://github.com/conventional-commits/conventionalcommits.org'
versions:
current: v1.0.0-beta.4
list:
- v1.0.0-beta.4
- v1.0.0-beta.3
de:
weight: 14
languageName: "Deutsch"
title: Konventionelle Commits
description: Eine Spezifikation für menschlich und maschinell lesbare Commit-Nachrichten
actions:
- label: Zusammenfassung
url: '#zusammenfassung'
- label: Spezifikation
url: '#spezifikation'
- label: Contribute
url: 'https://github.com/conventional-commits/conventionalcommits.org'
versions:
current: v1.0.0
list:
- v1.0.0
th:
weight: 15
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
uk:
weight: 16
languageName: "Ukrainian - Українська"
title: Політика Комітів
description: Угода для додавання зручних для читання коміт повідомлень для людей та роботів
actions:
- label: Швидкий Огляд
url: '#summary'
- label: Повна Специфікація
url: '#specification'
- label: Контрибуція
url: 'https://github.com/conventional-commits/conventionalcommits.org'
versions:
current: v1.0.0
list:
- v1.0.0
be:
weight: 17
languageName: "Belarusian - Беларуская"
title: Пагадненне аб камітах
description: Спецыфікацыя па дадаванню лёгкачытэльных паведамленняў у камітах для людзей і робатаў
actions:
- label: Сціслы агляд
url: '#сціслы-агляд'
- label: Поўная Спецыфікацыя
url: '#поўная-спецыфікацыя'
- label: Github
url: 'https://github.com/conventional-commits/conventionalcommits.org'
versions:
current: v1.0.0
list:
- v1.0.0
tr:
weight: 18
languageName: "Türkçe"
title: Conventional Commits
description: Conventional Commits şartnamesi, commit mesajları hakkında kolayca takip edilebilecek bir sözleşmedir
actions:
- label: Özet
url: '#özet'
- label: Şartname
url: '#şartname'
- label: Github
url: 'https://github.com/conventional-commits/conventionalcommits.org'
versions:
current: v1.0.0
list:
- v1.0.0
nl:
weight: 19
languageName: "Nederlands"
title: Conventionele Commits
description: Een specificatie voor mens- en machine-leesbare commit berichten
actions:
- label: Samenvatting
url: '#samenvatting'
- label: Specificatie
url: '#specificatie'
- label: GitHub
url: 'https://github.com/conventional-commits/conventionalcommits.org'
versions:
current: v1.0.0
list:
- v1.0.0
ml:
weight: 20
languageName: "Malayalam - മലയാളം"
title: കോൺവെൻഷനൽ കമ്മിറ്റ്സ്
description: സന്ദേശങ്ങൾ കമ്മിറ്റ് ചെയ്യാൻ മനുഷ്യനും യന്ത്രവും വായിക്കാവുന്ന അർത്ഥം ചേർക്കുന്നതിനുള്ള ഒരു സ്പെസിഫിക്കേഷൻ
actions:
- label: സംഗ്രഹം
url: '#സംഗ്രഹം'
- label: പൂർണ്ണ സ്പെസിഫിക്കേഷൻ
url: '#specification'
- label: Github
url: 'https://github.com/conventional-commits/conventionalcommits.org'
versions:
current: v1.0.0
list:
- v1.0.0
ro:
weight: 21
languageName: "Romanian"
title: Comiteri convenționale
description: O specificație pentru adăugarea unui sens care poate fi citit de om și de mașină pentru a comite mesaje
actions:
- label: Rezumat rapid
url: '#rezumat'
- label: Specificație completă
url: '#specificație'
- label: Contribuie
url: 'https://github.com/conventional-commits/conventionalcommits.org'
versions:
current: v1.0.0
list:
- v1.0.0
bn:
weight: 22
languageName: "বাংলা (Bengali)"
title: প্রচলিত কমিটসমূহ
description: কমিট বার্তায় মানুষ এবং মেশিন দ্বারা পাঠযোগ্য অর্থ যোগ করার জন্য একটি সবিস্তার বিবরণী।
actions:
- label: সারসংক্ষেপ
url: '#সারসংক্ষেপ'
- label: নির্দিষ্টকরণ রীতি
url: '#নির্দিষ্টকরণ'
- label: গিটহাব
url: 'https://github.com/conventional-commits/conventionalcommits.org'
versions:
current: v1.0.0
list:
- v1.0.0
uz:
weight: 23
languageName: "Uzbek (O'zbekcha)"
title: Conventional Commits
description: Commit xabarlariga inson va mashina o'qishi mumkin bo'ladigan ma'noni qo'shish uchun spesifikatsiya
actions:
- label: Xulosa
url: '#xulosa'
- label: Spesifikatsiya
url: '#spesifikatsiya'
- label: Github
url: 'https://github.com/conventional-commits/conventionalcommits.org'
versions:
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
ta:
weight: 20
languageName: "Tamil - தமிழ்"
title: வழக்கமான கமிட்கள்
description: செய்திகளை உறுதி செய்வதற்கு மனித மற்றும் இயந்திரம் படிக்கக்கூடிய பொருளைச் சேர்ப்பதற்கான விவரக்குறிப்பு.
actions:
- label: சுருக்கம்
url: '#summary'
- label: ஆவண விவரக்குறிப்பு
url: '#specification'
- label: பங்களிக்கவும்
url: 'https://github.com/conventional-commits/conventionalcommits.org'
versions:
current: v1.0.0
list:
- v1.0.0
pr:
weight: 26
languageName: "فارسی"
title: Conventional Commits
description: مشخصات برای اضافه کردن معانی خوانا برای اسنان و ماشین به پیام های کامیت
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
gr:
weight: 27
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
sr:
weight: 28
languageName: "Serbian - Srpski"
title: Conventional Commits
description: Specifikacija za dodavanje značenja porukama commit-ova koje je čitljivo i ljudima i mašinama.
actions:
- label: Kratak rezime
url: '#rezime'
- label: Puna specifikacija
url: '#specifikacija'
- label: Doprinos
url: 'https://github.com/conventional-commits/conventionalcommits.org'
versions:
current: v1.0.0
list:
- v1.0.0
si:
weight: 29
languageName: "Sinhala"
title: සම්මුතිවාදී කමිට්ස්
description: මිනිසුන්ට මෙන්ම යන්ත්රවලටද තේරුම් ගත හැකි අයුරින් කමිට් පණිවිඩවලට අර්ථයක් ලබා දීම සඳහා වූ පිරිවිතරයකි.
actions:
- label: සාරාංශය
url: '#summary'
- label: සම්පූර්ණ පිරිවිතරය
url: '#පිරිවිතරය'
- label: දායක වන්න
================================================
FILE: content/about/index.md
================================================
---
type: about
draft: false
---
# About
The Conventional Commits specification is inspired by, and based heavily on, the [Angular Commit Guidelines](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines).
The first draft of this specification has been written in collaboration with some of the folks contributing to:
* [conventional-changelog](https://github.com/conventional-changelog/conventional-changelog): a set of tools for parsing Conventional Commits messages from git histories.
* [parse-commit-message](https://npmjs.com/package/parse-commit-message): Extensible utilities for parsing, stringify and validating Conventional Commit messages.
* [bumped](https://bumped.github.io): a tool for releasing software that makes it easy to perform actions before and after releasing a new version of your software.
* [unleash](https://github.com/netflix/unleash): a tool for automating the software release and publishing lifecycle.
* [lerna](https://github.com/lerna/lerna): a tool for managing monorepos, which grew out of the Babel project.
## Tooling for Conventional Commits
* [go-conventional-commits](https://github.com/joselitofilho/go-conventional-commits): A tool to parser your git commit messages into a change log message based on conventional commits specification.
* [go-conventionalcommits](https://github.com/leodido/go-conventionalcommits): Full Go powers to parse conventional commits.
* [go-conventional-commit](https://gitlab.com/digitalxero/go-conventional-commit): go library for parsing commit messages following the specification.
* [chglog](https://github.com/goreleaser/chglog): a tool for parsing Conventional Commits messages from git histories and turning them into templateable change logs.
* [fastlane-plugin](https://github.com/xotahal/fastlane-plugin-semantic_release): follows the specification to manage versions and generate a changelog automatically.
* [commitizen/cz-cli](https://github.com/commitizen/cz-cli): A Node.js tool to create commit messages following the Conventional Commits specs.
* [commitizen-tools/commitizen](https://github.com/commitizen-tools/commitizen): A tool written in Python to create committing rules for projects, auto bump versions and auto changelog generation.
* [php-commitizen](https://github.com/damianopetrungaro/php-commitizen): A PHP tool built to create commit messages following the Conventional Commits specs.
Configurable and usable for PHP projects as a composer dependency or usable globally for non-PHP projects.
* [php-conventional-changelog](https://github.com/marcocesarato/php-conventional-changelog): a tool built to generate a changelog from a project's committing history messages and metadata and automate versioning with Semver, following Conventional Commits specs. Configurable and usable for PHP projects as a composer dependency or usable globally for non-PHP projects.
* [conventional-commits](https://github.com/ramsey/conventional-commits): A PHP library for creating and validating commit messages according to the Conventional Commits specification.
* [sh-conventional-commits](https://github.com/joaobsjunior/sh-conventional-commits) A hook that locally validates commit messages, checking if they follow the conventional commit pattern. The project also includes a shell script for generating semantic versions through conventional commits.
* [commitlint](https://github.com/conventional-changelog/commitlint): A linter to check that your commit messages meet the Conventional Commits format.
* [gitlint](https://github.com/jorisroovers/gitlint): Git commit message linter written in Python, which can be configured to [enforce Conventional Commits format](https://jorisroovers.com/gitlint/contrib_rules/#ct1-contrib-title-conventional-commits).
* [conform](https://github.com/autonomy/conform): a tool that can be used to enforce policies on git repositories, including Conventional Commits.
* [detect-next-version](https://npmjs.com/package/detect-next-version): Parse, detect and get more metadata about given Conventional Commits.
* [recommended-bump](https://www.npmjs.com/package/recommended-bump): Calculates the recommended version bump based on given Conventional Commits.
* [git-commits-since](https://www.npmjs.com/package/git-commits-since): Get all (raw) commits since period or (by default) from latest git SemVer tag, plus plugins support.
* [standard-version](https://github.com/conventional-changelog/standard-version): Automatic versioning and CHANGELOG management, using GitHub's new squash button and the recommended Conventional Commits workflow.
* [Conventional Commit](https://github.com/lppedd/idea-conventional-commit): provides extensible context and template-based completion, and inspections, for Conventional Commits inside the VCS Commit dialog. Available for all [JetBrains IDEs](https://www.jetbrains.com/).
* [Git Commit Template](https://plugins.jetbrains.com/plugin/9861-git-commit-template): Add Conventional Commits support to [JetBrains Editors](https://www.jetbrains.com/) (IntelliJ IDEA, PyCharm, PhpStorm...).
* [commitsar](https://github.com/commitsar-app/commitsar): Go tool for checking if commits on branch are Conventional Commits compliant. Comes with Docker image for CI uses.
* [semantic-release](https://github.com/semantic-release/semantic-release): A tool that automates the whole package release workflow including: determining the next version number, generating the release notes and publishing the package.
* [python-semantic-release](https://github.com/relekang/python-semantic-release): Automatic Semantic Versioning for Python projects. This is a Python implementation of the [semantic-release](https://github.com/semantic-release/semantic-release) for Node.js.
* [VSCode Conventional Commits](https://marketplace.visualstudio.com/items?itemName=vivaxy.vscode-conventional-commits): Add Conventional Commits supports for VSCode.
* [Pyhist](https://github.com/jgoodman8/pyhist): A Python utility to automagically update the package version from the git history and generate the Changelog.
* [git-mkver](https://github.com/idc101/git-mkver): A tool to automatically apply Semantic Versioning to git repositories based on _Conventional Commits_.
* [git-semver](https://github.com/PSanetra/git-semver): A cli tool for calculating the next semantic version according to latest _Conventional Commits_ and printing changelogs to stdout.
* [Conventional Commits Next Version](https://gitlab.com/DeveloperC/conventional_commits_next_version): A tooling and language agnostic utility to calculate the next semantic version based on the _Conventional Commits_ since the prior version. Supports monorepos.
* [change](https://github.com/adamtabrams/change): A tool for generating and updating a changelog using Conventional Commits.
* [Turbogit](https://b4nst.github.io/turbogit): A command line tool to help you follow _Conventional Commits_ flow.
* [sv4git](https://github.com/bvieira/sv4git): A command line tool (CLI) to validate commit messages, bump versions, create tags and generate changelogs.
* [Versio](https://github.com/chaaz/versio): A monorepo-compatible tool that updates version numbers based on conventional commits and project dependencies. It can generate tags and changelogs, too.
* [Git Changelog Lib](https://github.com/tomasbjerre/git-changelog-lib): A Java library that supports rendering a changelog given a context derived from Git. Supports conventional commits with [Handlebars Helpers](https://github.com/tomasbjerre/git-changelog-lib#helpers). It is used in:
* [Gradle](https://github.com/tomasbjerre/git-changelog-gradle-plugin)
* [Maven](https://github.com/tomasbjerre/git-changelog-maven-plugin)
* [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.
* [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.
* [EasyBuild ecosystem](https://github.com/easybuild-org): A collection of tools for automating release using Conventional Commits.
* [EasyBuild.CommitLinter](https://github.com/easybuild-org/EasyBuild.CommitLinter): A .NET CLI tool to lint your commit messages
* [EasyBuild.ChangelogGen](https://github.com/easybuild-org/EasyBuild.ChangelogGen): A .NET CLI tool for generating changelog based on Git history following Conventional Commits.
## Projects Using Conventional Commits
* [NFPM](https://github.com/goreleaser/nfpm): NFPM is Not FPM - a simple deb, rpm and apk packager written in Go.
* [yargs](https://github.com/yargs/yargs): everyone's favorite pirate themed command line argument parser.
* [istanbuljs](https://github.com/istanbuljs/istanbuljs): a collection of open-source tools and libraries for adding test coverage to your JavaScript tests.
* [uPortal-home](https://github.com/UW-Madison-DoIT/angularjs-portal) and [uPortal-application-framework](https://github.com/UW-Madison-DoIT/uw-frame): Optional supplemental user interface enhancing [Apereo uPortal](https://www.apereo.org/projects/uportal).
* [massive.js](https://github.com/dmfay/massive-js): A data access library for Node and PostgreSQL.
* [electron](https://github.com/electron/electron): Build cross-platform desktop apps with JavaScript, HTML, and CSS.
* [scroll-utility](https://github.com/LeDDGroup/scroll-utility): A simple to use scroll utility package for centering elements, and smooth animations
* [Blaze UI](https://github.com/BlazeUI/blaze): Framework-free open source UI toolkit.
* [Monica](https://github.com/monicahq/monica): An open source personal relationship management system.
* [mhy](https://mhy.js.org): A zero-config, out-of-the-box, multi-purpose toolbox and development environment.
* [@tandil/diffparse](https://github.com/danielduarte/diffparse#readme): Simple parser for Diff files (unified diff format).
* [@tandil/diffsplit](https://github.com/danielduarte/diffsplit#readme): Easy split of .diff & .patch into its files.
* [@thi.ng/umbrella](https://github.com/thi-ng/umbrella): Broadly scoped ecosystem & monorepo of ~185 TypeScript projects for general purpose, functional, data driven development
* [yii2-basic-firestarter](https://github.com/HunWalk/yii2-basic-firestarter): 🔥 An enhanced Yii2 app template.
* [dcyou/resume](https://github.com/dcyou/resume): 😎 Template to easily and quickly create your online CV.
* [Nintex Forms](https://www.nintex.com/workflow-automation/modern-forms/): Easily create dynamic online forms to capture and submit accurate and current data.
* [Tina CMS](https://tinacms.org): An open source toolkit for building front-end content-management into your website.
* [Belajarpython](https://github.com/belajarpythoncom/belajarpython.com) Open source Indonesian python programming tutorial site.
* [Uno Platform](https://platform.uno): Build Mobile, Desktop and WebAssembly apps with C# and XAML. Today. Open source and professionally supported.
* [Jenkins X](https://jenkins-x.io/): Jenkins X provides pipeline automation, built-in GitOps, and preview environments to help teams collaborate and accelerate their software delivery at any scale.
* [GearLock](https://github.com/axonasif/gearlock): Custom Recovery Replacement for Android-x86.
* [Changeloguru](https://github.com/haunt98/changeloguru): Auto-generate changelog from conventional commits, written in Go.
* [freeCodeCamp](https://www.freecodecamp.org): A nonprofit community that helps you learn to code by building projects.
[](https://conventionalcommits.org)
_want your project on this list?_ [send a pull request](https://github.com/conventional-changelog/conventionalcommits.org/pulls).
================================================
FILE: content/next/index.md
================================================
---
draft: true
---
# Conventional Commits 1.0.0-next
## Summary
The Conventional Commits specification is a lightweight convention on top of commit messages.
It provides an easy set of rules for creating an explicit commit history;
which makes it easier to write automated tools on top of.
This convention dovetails with [SemVer](http://semver.org),
by describing the features, fixes, and breaking changes made in commit messages.
The commit message should be structured as follows:
---
```
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
```
---
<br />
The commit contains the following structural elements, to communicate intent to the
consumers of your library:
1. **fix:** a commit of the _type_ `fix` patches a bug in your codebase (this correlates with [`PATCH`](http://semver.org/#summary) in Semantic Versioning).
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 a footer `BREAKING CHANGE:`, or appends a `!` after the type/scope, introduces a breaking API change (correlating with [`MAJOR`](http://semver.org/#summary) when the version >= 1.0.0, and [`MINOR`](https://semver.org/#spec-item-4) when on a pre-release 0.y.z version, in Semantic Versioning).
A BREAKING CHANGE can be part of commits of any _type_.
1. **INITIAL STABLE RELEASE:** a commit that has a footer `INITIAL STABLE RELEASE:`, or appends `!!` after the type/scope, and introduces a new `MAJOR` even on versions `< 1.0.0`, denoting the promotion from a pre-release version `0.y.z` to `1.0.0`.
1. _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 [the Angular convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) recommends `build:`, `chore:`,
`ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, and others.
1. _footers_ other than `BREAKING CHANGE: <description>` or `INITIAL STABLE RELEASE: <description>` may be provided and follow a convention similar to
[git trailer format](https://git-scm.com/docs/git-interpret-trailers).
Additional types are not mandated by the conventional commits specification, and have no implicit effect in Semantic Versioning (unless they include a BREAKING CHANGE, or mark an INITIAL STABLE RELEASE).
<br /><br />
A scope may be provided to a commit's type, to provide additional contextual information and is contained within parentheses, e.g., `feat(parser): add ability to parse arrays`.
## Examples
### Commit message with description and breaking change 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
```
### Commit message with `!` to draw attention to breaking change
```
feat!: send an email to the customer when a product is shipped
```
### Commit message with scope and `!` to draw attention to breaking change
```
feat(api)!: send an email to the customer when a product is shipped
```
### Commit message with both `!` and BREAKING CHANGE footer
```
feat!: drop support for Node 6
BREAKING CHANGE: use JavaScript features not available in Node 6.
```
### Commit message with `!!` to mark graduating to Production Version 1.0.0
```
feat!!: send an email to the customer when a product is shipped
```
### Commit message with `!!` and INITIAL STABLE RELEASE footer
```
feat!!: send an email to the customer when a product is shipped
INITIAL STABLE RELEASE: the API is now ready for use by the general public
```
### Commit message with description and INITIAL STABLE RELEASE footer
```
feat: send an email to the customer when a product is shipped
INITIAL STABLE RELEASE: the API is now ready for use by the general public
```
### Commit message with no body
```
docs: correct spelling of CHANGELOG
```
### Commit message with scope
```
feat(lang): add polish language
```
### Commit message with multi-paragraph body and multiple 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
```
## Specification
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
1. Commits MUST be prefixed with a type, which consists of a noun, `feat`, `fix`, etc., followed
by the OPTIONAL scope, OPTIONAL `!`, OPTIONAL second `!`, and REQUIRED terminal colon and space.
1. The type `feat` MUST be used when a commit adds a new feature to your application or library.
1. The type `fix` MUST be used when a commit represents a bug fix for your application.
1. A scope MAY be provided after a type. A scope MUST consist of a noun describing a
section of the codebase surrounded by parentheses, e.g., `fix(parser):`
1. A description MUST immediately follow the colon and space after the type/scope prefix.
The description is a short summary of the code changes, e.g., _fix: array parsing issue when multiple spaces were contained in string_.
1. A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description.
1. A commit body is free-form and MAY consist of any number of newline separated paragraphs.
1. One or more footers MAY be provided one blank line after the body. Each footer MUST consist of
a word token, followed by either a `:<space>` or `<space>#` separator, followed by a string value (this is inspired by the
[git trailer convention](https://git-scm.com/docs/git-interpret-trailers)).
1. A footer's token MUST use `-` in place of whitespace characters, e.g., `Acked-by` (this helps differentiate
the footer section from a multi-paragraph body). An exception is made for `BREAKING CHANGE` and `INITIAL STABLE RELEASE`, which MAY also be used as a token.
1. A footer's value MAY contain spaces and newlines, and parsing MUST terminate when the next valid footer
token/separator pair is observed.
1. Breaking changes MUST be indicated in the type/scope prefix of a commit, or as an entry in the
footer.
1. If included as a footer, a breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon, space, and description, e.g.,
_BREAKING CHANGE: environment variables now take precedence over config files_.
1. If included in the type/scope prefix, breaking changes MUST be indicated by a
`!` immediately before the `:`. If `!` is used, `BREAKING CHANGE:` MAY be omitted from the footer section,
and the commit description SHALL be used to describe the breaking change.
1. Types other than `feat` and `fix` MAY be used in your commit messages, e.g., _docs: updated ref docs._
1. The units of information that make up conventional commits MUST NOT be treated as case-sensitive by implementors, with the exception of BREAKING CHANGE and INITIAL STABLE RELEASE which MUST be uppercase.
1. BREAKING-CHANGE MUST be synonymous with BREAKING CHANGE, when used as a token in a footer.
1. Graduating a pre-release 0.y.z version to 1.0.0 MUST be signaled by at least one of:
1. Including `!!` in the type/scope prefix immediately before the `:`
1. Providing `INITIAL STABLE RELEASE:` in the footer section.
## Why Use Conventional Commits
* Automatically generating CHANGELOGs.
* Automatically determining a semantic version bump (based on the types of commits landed).
* Communicating the nature of changes to teammates, the public, and other stakeholders.
* Triggering build and publish processes.
* Making it easier for people to contribute to your projects, by allowing them to explore
a more structured commit history.
## FAQ
### How should I deal with commit messages in the initial development phase?
We recommend that you proceed as if you've already released the product. Typically *somebody*, even if it's your fellow software developers, is using your software. They'll want to know what's fixed, what breaks etc.
### Are the types in the commit title uppercase or lowercase?
Any casing may be used, but it's best to be consistent.
### What do I do if the commit contains changes of more than one type?
Go back and make multiple commits whenever possible. Part of the benefit of Conventional Commits is its ability to drive us to make more organized commits and PRs.
### Doesn’t this discourage rapid development and fast iteration?
It discourages moving fast in a disorganized way. It helps you be able to move fast long term across multiple projects with varied contributors.
### Might Conventional Commits lead developers to limit the type of commits they make because they'll be thinking in the types provided?
Conventional Commits encourages us to make more of certain types of commits such as fixes. Other than that, the flexibility of Conventional Commits allows your team to come up with their own types and change those types over time.
### How does this relate to SemVer?
`fix` type commits should be translated to `PATCH` releases. `feat` type commits should be translated to `MINOR` releases. Commits with `BREAKING CHANGE` in the commits, regardless of type, should be translated to `MAJOR` releases.
### How should I version my extensions to the Conventional Commits Specification, e.g. `@jameswomack/conventional-commit-spec`?
We recommend using SemVer to release your own extensions to this specification (and
encourage you to make these extensions!)
### What do I do if I accidentally use the wrong commit type?
#### When you used a type that's of the spec but not the correct type, e.g. `fix` instead of `feat`
Prior to merging or releasing the mistake, we recommend using `git rebase -i` to edit the commit history. After release, the cleanup will be different according to what tools and processes you use.
#### When you used a type *not* of the spec, e.g. `feet` instead of `feat`
In a worst case scenario, it's not the end of the world if a commit lands that does not meet the conventional commit specification. It simply means that commit will be missed by tools that are based on the spec.
### Do all my contributors need to use the conventional commit specification?
No! If you use a squash based workflow on Git, lead maintainers can clean up the commit messages as they're merged—adding no workload to casual committers.
A common workflow for this is to have your git system automatically squash commits from a pull request and present a form for the lead maintainer to enter the proper git commit message for the merge.
### How does Conventional Commits handle revert commits?
Reverting code can be complicated: are you reverting multiple commits? if you revert a feature, should the next release instead be a patch?
Conventional Commits does not make an explicit effort to define revert behavior. Instead we leave it to tooling
authors to use the flexibility of _types_ and _footers_ to develop their logic for handling reverts.
One recommendation is to use the `revert` type, and a footer that references the commit SHAs that are being reverted:
```
revert: let us never again speak of the noodle incident
Refs: 676104e, a215868
```
### What writing form should I use?
We recommend writing a commit description and body using the [imperative](https://en.wikipedia.org/wiki/Imperative_mood) present tense writing form.
There are a significant number of examples of this writing form for commits [1](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)[2](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#subject)[3](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project)[4](https://medium.com/@danielfeelfine/commit-verbs-101-why-i-like-to-use-this-and-why-you-should-also-like-it-d3ed2689ef70)[5](https://chris.beams.io/posts/git-commit/)
## About
The Conventional Commit specification is inspired by, and based heavily on, the [Angular Commit Guidelines](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines).
The first draft of this specification has been written in collaboration with some of the folks contributing to:
* [conventional-changelog](https://github.com/conventional-changelog/conventional-changelog): a set of tools for parsing conventional commit messages from git histories.
* [bumped](https://bumped.github.io): a tool for releasing software that makes it easy to perform actions before and after releasing a new version of your software.
* [unleash](https://github.com/netflix/unleash): a tool for automating the software release and publishing lifecycle.
* [lerna](https://github.com/lerna/lerna): a tool for managing monorepos, which grew out of the Babel project.
## Tooling for Conventional Commits
* [go-conventionalcommits](https://github.com/leodido/go-conventionalcommits): Full Go powers to parse conventional commits
* [go-conventional-commit](https://gitlab.com/digitalxero/go-conventional-commit): go library for parsing commit messages following the specification.
* [chglog](https://github.com/goreleaser/chglog): a tool for parsing Conventional Commits messages from git histories and turning them into templateable change logs.
* [fastlane-plugin](https://github.com/xotahal/fastlane-plugin-semantic_release): follows the specification to manage versions and generate a changelog automatically.
* [php-commitizen](https://github.com/damianopetrungaro/php-commitizen): a tool built to create commit messages following the Conventional Commit specs.
Configurable and usable for PHP projects as a composer dependency or usable globally for non-PHP projects.
* [php-conventional-changelog](https://github.com/marcocesarato/php-conventional-changelog): a tool built to generate a changelog from a project's committing history messages and metadata and automate versioning with Semver, following Conventional Commits specs. Configurable and usable for PHP projects as a composer dependency or usable globally for non-PHP projects.
* [conform](https://github.com/autonomy/conform): a tool that can be used to enforce policies on git repositories, including conventional commits.
* [standard-version](https://github.com/conventional-changelog/standard-version): Automatic versioning and CHANGELOG management, using GitHub's new squash button and the recommended Conventional Commits workflow.
* [Git Commit Template](https://plugins.jetbrains.com/plugin/9861-git-commit-template): Add _Conventional Commits_ support to [JetBrains Editors](https://www.jetbrains.com/) (IntelliJ IDEA, PyCharm, PhpStorm...).
* [commitsar](https://github.com/commitsar-app/commitsar): Go tool for checking if commits on branch are conventional commit compliant. Comes with Docker image for CI uses.
* [semantic-release](https://github.com/semantic-release/semantic-release): A tool that automates the whole package release workflow including: determining the next version number, generating the release notes and publishing the package.
* [ngx-semantic-version](https://github.com/d-koppenhagen/ngx-semantic-version): Automate your Angular app commit- and release-workflow by integrating _commitizen_, _commitlint_, _husky_ and _standard-version_ in your project and configuring it for using _Conventional Commits_.
* [Pyhist](https://github.com/jgoodman8/pyhist): A Python utility to automagically update the package version from the git history and generate the Changelog.
* [commitizen-tools/commitizen](https://github.com/commitizen-tools/commitizen): A Python tool built to create committing rules for projects (default: conventional commit), bump project versions, and generate changelog. Configurable and usable for both Python and non-Python project. It's highly extensible through Python.
* [git-mkver](https://github.com/idc101/git-mkver): A tool to automatically apply Semantic Versioning to git repositories based on _Conventional Commits_.
* [Conventional Commits Next Version](https://gitlab.com/DeveloperC/conventional_commits_next_version): A tooling and language agnostic utility to calculate the next semantic version based on the _Conventional Commits_ since the prior version. Supports monorepos.
* [change](https://github.com/adamtabrams/change): A tool for generating and updating a changelog using Conventional Commits.
* [sv4git](https://github.com/bvieira/sv4git): A command line tool (CLI) to validate commit messages, bump versions, create tags and generate changelogs.
* [semantic-gitlog](https://github.com/semantic-gitlog) A simple Semantic Versioning management tool based on Conventional Commits. It automatically derives and manage version numbers and generate angular-style changelogs. supports [Maven](https://github.com/semantic-gitlog/maven-semantic-gitlog) and [Gradle](https://github.com/semantic-gitlog/gradle-semantic-gitlog).
* [idea-conventional-commit](https://github.com/lppedd/idea-conventional-commit) Context and template-based completion for conventional/semantic commits.
* [Versio](https://github.com/chaaz/versio): A monorepo-compatible tool that updates version numbers based on conventional commits and project dependencies. It can generate tags and changelogs, too.
* [Git Changelog Lib](https://github.com/tomasbjerre/git-changelog-lib): A Java library that supports rendering a changelog given a context derived from Git. Supports conventional commits with [Handlebars Helpers](https://github.com/tomasbjerre/git-changelog-lib#helpers). It is used in:
* [Gradle](https://github.com/tomasbjerre/git-changelog-gradle-plugin)
* [Maven](https://github.com/tomasbjerre/git-changelog-maven-plugin)
* [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
## Projects Using Conventional Commits
* [NFPM](https://github.com/goreleaser/nfpm): NFPM is Not FPM - a simple deb, rpm and apk packager written in Go
* [yargs](https://github.com/yargs/yargs): everyone's favorite pirate themed command line argument parser.
* [istanbuljs](https://github.com/istanbuljs/istanbuljs): a collection of open-source tools and libraries for adding test coverage to your JavaScript tests.
* [uPortal-home](https://github.com/UW-Madison-DoIT/angularjs-portal) and [uPortal-application-framework](https://github.com/UW-Madison-DoIT/uw-frame): Optional supplemental user interface enhancing [Apereo uPortal](https://www.apereo.org/projects/uportal).
* [massive.js](https://github.com/dmfay/massive-js): A data access library for Node and PostgreSQL.
* [electron](https://github.com/electron/electron): Build cross-platform desktop apps with JavaScript, HTML, and CSS.
* [scroll-utility](https://github.com/LeDDGroup/scroll-utility): A simple to use scroll utility package for centering elements, and smooth animations.
* [Blaze UI](https://github.com/BlazeUI/blaze): Framework-free open source UI toolkit.
* [Monica](https://github.com/monicahq/monica): An open source personal relationship management system.
* [mhy](https://mhy.js.org): 🧩 A zero-config, out-of-the-box, multi-purpose toolbox and development environment.
* [@tandil/diffparse](https://github.com/danielduarte/diffparse#readme): Simple parser for Diff files (unified diff format).
* [@tandil/diffsplit](https://github.com/danielduarte/diffsplit#readme): Easy split of .diff & .patch into its files.
* [@thi.ng/umbrella](https://github.com/thi-ng/umbrella): Monorepo of ~100 TypeScript projects for data driven development.
* [yii2-basic-firestarter](https://github.com/HunWalk/yii2-basic-firestarter): 🔥 An enhanced Yii2 app template.
* [Nintex Forms](https://www.nintex.com/workflow-automation/modern-forms/): Easily create dynamic online forms to capture and submit accurate and current data.
* [Tina CMS](https://tinacms.org): An open source toolkit for building front-end content-management into your website.
* [Uno Platform](https://platform.uno): Build Mobile, Desktop and WebAssembly apps with C# and XAML. Today. Open source and professionally supported.
* [AutoSort.NetCore](https://www.nuget.org/packages/AutoSort.NetCore/): Use entity attributes for default sorting.
* [Undercut](https://github.com/the-spyke/undercut): JavaScript lazy data processing pipelines and utilities.
* [Stats Builder](https://github.com/MarkFChavez/blox_piece_stats_builder): A stats builder for [Blox Fruits](https://www.roblox.com/games/2753915549/UPDATE-11-Blox-Fruits)
* [Jenkins X](https://jenkins-x.io/): Jenkins X provides pipeline automation, built-in GitOps, and preview environments to help teams collaborate and accelerate their software delivery at any scale.
* [GearLock](https://github.com/axonasif/gearlock): Custom Recovery Replacement for Android-x86.
* [rsql-querydsl](https://github.com/ymind/rsql-querydsl): Integration RSQL query language and Querydsl framework.
* [Changeloguru](https://github.com/haunt98/changeloguru): Auto-generate changelog from conventional commits, written in Go.
[](https://conventionalcommits.org)
_want your project on this list?_ [send a pull request](https://github.com/conventional-changelog/conventionalcommits.org/pulls).
================================================
FILE: content/v1.0.0/index.ar.md
================================================
---
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 لتغيير جذري
```
feat!: 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
```
================================================
FILE: content/v1.0.0/index.be.md
================================================
---
draft: false
aliases: ["/be/"]
---
# Пагадненне аб камітах 1.0.0
## Сціслы агляд
Спецыфікацыя па дадаванню лёгкачытэльных паведамленняў у камітах для людзей і робатаў.
Яно апісвае просты набор правілаў для стварэння зразумелай гісторыі камітаў, а таксама
дазваляе прасцей распрацоўваць прылады
аўтаматызацыі, заснаваныя на гісторыі камітаў. Дадзенае пагадненне сумяшчальна з
[Семантычным Версіянаваннем](https://semver.org/), апісваючы новыя функцыі, выпраўленні і
змяненні, парушаючыя адваротную сумяшчальнасць паведамленняў камітаў.
Паведамленні камітаў павінны быць наступнай структуры:
---
```
<тып>[неабавязковы кантэкст]: <апісанне>
[неабавязковае цела]
[неабавязковая(ыя) зноска(і)]
```
---
<br />
Каміт змяшчае наступныя структурныя элементы для перадачы намераў
карыстыльнікаў вашай бібліятэкі:
1. **fix:** каміт _тыпу_ `fix` выпраўляе баг у вашам кодзе (адпавядае
[`PATCH`](https://semver.org/#summary) у Семантычным Версіянаванні).
1. **feat:** каміт _тыпу_ `feat` дадае новую функцыю ў ваш код
(адпавядае [`MINOR`](https://semver.org/#summary) у Семантычным Версіянаванні).
1. **BREAKING CHANGE:** каміт, які мае _зноску_ `BREAKING CHANGE` або
каміт, які скончваецца клічнікам (`!`) пасля _тыпу_ ці
_кантэксту_, уводзячы змяненне(і), парушаючыя адваротную сумяшчальнасць
(адпавядае [`MAJOR`](https://semver.org/#summary) у Семантычным Версіянаванні).
`BREAKING CHANGE` можа быць часткай каміту любога _тыпу_.
1. Іншыя _тыпы_ камітаў дазволены. Напрыклад,
[@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` і іншыя.
1. Іншыя _зноскі_ камітаў могуць быць аналягічны паведамленню [git trailer format](https://git-scm.com/docs/git-interpret-trailers).
Дадатковыя _тыпы_ не патрабуюцца «Пагадненню аб камітах» і ня маюць невідавочнага
эфекту ў семантычным версіянаванні (калі толькі яны не ўключаюць
`BREAKING CHANGE`).
<br /><br />
_Кантэкст_ можа быць дададзены да _тыпу_ каміту, каб даць
дадатковую кантэкстную інфармацыю; яна трываецца ў дужках. Напрыклад,
`feat(parser): add ability to parse arrays`.
## Прыклады
### Паведамленне каміту з _апісаннем_ і _зноскай_ `BREAKING CHANGE`
```
feat: allow provided config object to extend other configs
BREAKING CHANGE: `extends` key in config file is now used for extending other config files
```
### Паведамленне каміту з `!` для звяртання ўвагі на `BREAKING CHANGE`
```
feat!: send an email to the customer when a product is shipped
```
### Паведамленне каміту з _кантэкстам_ і `!` для звяртання ўвагі на `BREAKING CHANGE`
```
feat(api)!: send an email to the customer when a product is shipped
```
### Паведамленне каміту разам з `!` і _зноскай_ `BREAKING CHANGE`
```
feat!: drop support for Node 6
BREAKING CHANGE: use JavaScript features not available in Node 6.
```
### Паведамленне каміту бяз _цела_
```
docs: correct spelling of CHANGELOG
```
### Паведамленне каміту з _кантэкстам_
```
feat(lang): add polish language
```
### Паведамленне каміту с _целам_ з некалькіх абзацаў і некалькімі _зноскамі_
```
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», «MAY» и «OPTIONAL» у дадзенам
дакуменце павінна тлумачыцца як у [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
1. Каміты павінны (MUST) пачынацца з _тыпу_, які з'яўляецца назоўнікам:
`feat`, `fix` і г.д. За ім ідзе неабавязковы (OPTIONAL) _кантэкст_,
неабавязковы (OPTIONAL) клічнік (`!`) і абавязковае
(REQUIRED) двукроп'е (`:`) і прабел (` `).
1. _Тып_ `feat` павінны (MUST) выкарыстоўвацца, калі каміт дадае новы
функцыянал у ваша прыкладанне або вашу бібліятэку.
1. _Тып_ `fix` павінны (MUST) выкарыстоўвацца, калі каміт выпраўляе баг у
вашам прыкладанні ці ў вашай бібліятэцы.
1. _Кантэкст_ можа (MAY) ісці пасля _тыпу_. _Кантэкст_ павінны (MUST)
быць назоўнікам, заключаным у круглыя дужкі, апісваючы частку
кодавай базы, якую закрануў каміт. Напрыклад, `fix(parser)`.
1. _Апісанне_ павінна (MUST) ісці адразу пасля двукроп'я (`:`) і з прабелам
(` `) пасля _тыпу_ або _кантэксту_. _Апісанне_ ўяўляе сабой сціслае выкладанне змен коду. Напрыклад, `fix: array parsing issue when multiple
spaces were contained in string`.
1. _Цела_ каміту можа (MAY) ісці пасля сціслага _апісання_, дадаючы дадатковую кантэкстную інфармацыю пра змены ў кодзе. _Цела_ павінна
(MUST) аддзяляцца ад _апісання_ адным пустым радком.
1. _Цела_ каміту мае самавольную форму и можа (MAY) складацца з любой колькасці абзацаў, падзеленых новым радком.
1. У адной ці некалькіх _зносках_ можа (MAY) быць адзін пусты радок пасля
_цела_. Кожная _зноска_ павінна (MUST) складацца з токена слову, за якім
ідзе раздзяляльнік `:<прабел>` ці `<прабел>#`, за якім ідзе
радковае значэнне (заснавана на [git trailer format](https://git-scm.com/docs/git-interpret-trailers)).
1. Токен _зноскі_ павінны (MUST) карыстаць `-` замест прабельных сымбаляў.
Напрыклад, `Acked-by` (гэта дапамагае адрозніць раздзел _зноскі_ ад яго _цела_,
складаючагася з некалькіх абзацаў). Выключэнне складае `BREAKING CHANGE`,
якое можа (MAY) таксама выкарыстоўвацца як токен.
1. _Зноска_ можа (MAY) змяшчаць прабелы і сымбалі новага радку, а счытванне
павінна (MUST) завяршацца пры выяўленні наступнай дапушчальнай пары
токен-раздзяляльнік _зноскі_.
1. Крытычныя змяненні павінны (MUST) быць указаны ў _тыпу_, _кантэксту_ або
_зносцы_ каміту.
1. Калі `BREAKING CHANGE` уключана ў _зноску_, то яно павінна (MUST) спалучацца з
вялікіх літар ў тэксце `BREAKING CHANGE`, за якім ідзе двукроп'е (`:`),
прабел (` `) і _апісанне_. Напрыклад, `BREAKING CHANGE: environment
variables now take precedence over config files`.
1. Калі крытычныя змяненні знаходзяцца ў _тыпу_ або _кантэксту_, то яны павінны
(MUST) быць пазначаны клічнікам (`!`), непасрэдна перад двукроп'ем (`:`). Калі выкарыстоўваецца клічнік (`!`), то
`BREAKING CHANGE` можа (MAY) быць апушчаны ў _зносцы_, а _апісанне_ каміту павінна (SHALL) выкарыстоўвацца для апісання крытычнага змянення.
1. У вашых паведамленнях камітаў могуць (MAY) выкарыстоўвацца _тыпы_, адменныя ад
`feat` і `fix`. Напрыклад, `docs: updated ref docs`.
1. Адзінкі інфармацыі, якія складаюць «Пагадненне аб камітах», не павінны
(MUST NOT) апрацоўвацца распрацоўнікамі як адчувальныя да рэгістру, за
выключэннем `BREAKING CHANGE`, каторае павінна (MUST) пісацца вялікімі літарамі.
1. `BREAKING-CHANGE` павінны (MUST) быць сінонімам `BREAKING CHANGE` пры
выкарыстоўванні ў якасці токена ў _зносцы_.
## Навошта выкарыстоўваць «Пагадненне аб камітах»
* Аўтаматычнае стварэнне спісаў змяненняў.
* Аўтаматычнае вызначэнне семантычнага павышэння версіі (на падставе _тыпаў_
здзейсненых камітаў).
* Інфармаванне сябраў па камандзе, супольнасці і іншых зацікаўленых старон аб характары змяненняў.
* Запуск працэсаў зборкі і публікацыі.
* Спрасціце людзям удзел у вашых праектах, дазволіўшы ім вывучаць больш
структураваную гісторыі камітаў.
## FAQ (часта задаваныя пытанні)
### Як мне абысціся з паведамленнямі камітаў на пачатковым этапе распрацоўкі?
Мы раім дзейнічаць так, быццам бы вы ўжо выпусцілі прадукт. Звычайна
*хтосьці*, нават калі то вашыя калегі-распрацоўнікі праграмнага забеспячэння,
карыстаецца вашым праграмным забеспячэннем. Яны пажадаюць ведаць, што выпраўлена,
што ламаецца і г.д.
### _Тыпы_ ў загалоўку каміту павінны пісацца вялікімі ці маленікімі літарамі?
Выбярыце той, які вам больш падабаецца, і строга яго прытрымлівайцеся.
### Што мне рабіць, калі каміт адпавядае больш чым аднаму _тыпу_?
Па магчымасці вярніцеся назад і зрабіце некалькі камітаў. Часткай
перавагі «Пагаднення аб камітах» з'яўляецца здольнасць заахвочваць нас рабіць
больш арганізаваныя каміты і PRs (pull requests, ці
запыты на запросы на выцягванне).
### Хіба то не перашкаджае інтэнсіўнай распрацоўцы і хуткай ітэрацыі?
Гэта перашкаджае хуткаму неарганізаванаму руху. Гэта дапаможа вам хутка прасоўвацца ў доўгатэрміновай перспектыве ў некалькіх праектах з рознымі ўдзельнікамі.
### Ці можа «Пагадненне аб камітах» прывесці распрацоўнікаў да абмежавання _тыпаў_ здзейсненых імі камітаў, таму што яны будуць думаць у адпаведнасці з дазволенымі _тыпамі_?
«Пагадненне аб камітах» схіляе нас рабіць больш вызначаных _тыпаў_
камітаў, такіх, як `fix`. Акрамя гэтага, гібкасць «Пагаднення аб камітах»
дазваляе вашай камандзе прыдумваць свае асабістыя _тыпы_ і з цягам часу змяняць іх.
### Як гэта звязана з Семантычным Версіянаваннем?
Каміты _тыпу_ `fix` павінны быць пераведзены ў выпускі `PATCH`, `feat` — у
`MINOR`, `BREAKING CHANGE`, незалежна ад _тыпу_, — у `MAJOR`.
### Як мне давесці свае расшырэнні да спецыфікацыі «Пагадненне аб камітах». Напрыклад, `@jameswomack/standard-commit-spec`?
Мы раім выкарыстоўваць Семантычнае Версіянаванне для выпуску
вашых уласных расшырэнняў для гэтай спецыфікацыі (і заклікаем вас ствараць гэтыя расшырэнні!).
### Што мне рабіць, калі я выпадкова скарыстаў няправільны _тып_ каміту?
#### Калі вы скарысталі няправільны _тып_, але адпаведны спецыфікацыі. Напрыклад, `fix` замест `feat`
Перад аб'яднаннем або выпускам памылкі мы раім выкарыстоўваць `git rebase
-i` для рэдагавання гісторыі камітаў. Пасля выпуску рэдагаванне будзе адрознівацца ў залежнасці ад таго, якія прылады і працэсы вы выкарыстоўваеце.
#### Калі вы скарысталі _тып_, не прызначаны у спецыфікацыі. Напрыклад, `feet` замест `feat`
У горшым выпадку гэта ўсё яшчэ не канец свету, калі каміт не адпавядае
спецыфікацыі «Пагаднення аб камітах». Гэта проста азначае, што каміт будзе прапушчаны прыладамі, заснаванымі на спецыфікацыі.
### Ці ўсе мае ўдзельнікі павінны карыстацца спецыфікацыяй «Пагаднення аб камітах»?
Не! Калі вы выкарыстоўваеце рабочы працэс на падставе з'яднання (squash)
камітаў у Git, то вядучыя спецыялісты па суправаджэнню могуць прывесці ў парадак паведамленні камітаў па меры іх зліцця (merge), не дадаючы нагрузкі для звычайных камітараў. Звычайны рабочы працэс для гэтага і заключаецца ў тым, каб ваша сістэма Git аўтаматычна з'яднала каміты з PR і прывяла форму для
вядучага суправаджаючага, каб увесці найбольш падыходзячае паведамленне для зліцця.
### Як «Пагадненне аб камітах» апрацоўвае скасаванне камітаў?
Скасаванне змяненняў коду можа быць складаным:
- Вы скасоўваеце змяненні некалькіх камітаў?
- Калі вы скасоўваеце змяненні новых функцый, ці павінны наступны выпуск быць
патчам?
«Пагадненне аб камітах» ня робіць яўных спробаў вызначыць паводзіны скасавання змен. Замест гэтага мы пакідаем аўтарам прылад выкарыстоўваць гібкасць _тыпаў_ і _зносак_ для распрацоўкі сваёй лёгікі і для апрацоўкі скасавання змен.
Адна з парад — выкарыстоўваць _тып_ `revert` і _зноску_, якая
спасылаецца на касаваныя хэш-сумы камітаў. Напрыклад:
```
revert: let us never again speak of the noodle incident
Refs: 676104e, a215868
```
================================================
FILE: content/v1.0.0/index.bn.md
================================================
---
draft: false
aliases: ["/bn/"]
---
# প্রচলিত কমিটসমূহ ১.০.০
Conventional Commits 1.0.0
> Commit এর বাংলা অর্থ দাঁড়ায় **'সমর্পণ করা'** বা **'সোপর্দ করা'**, কিন্তু আমরা এখানে **"কমিট"** শব্দটিই ব্যবহার করবো। গিট বা অন্যান্য সফটওয়্যার ডেভেলপমেন্ট প্ল্যাটফর্মে কমিট হলো এমন একটি প্রক্রিয়া যার মাধ্যমে নতুন পরিবর্তনগুলি সংরক্ষণ করা হয়।
## সারসংক্ষেপ
**প্রচলিত কমিটসমূহের নির্দিষ্টকরণ (রীতি)** হলো কমিট বার্তার (commit messages) উপরে একটি সহজতর প্রচলন। এটি একটি সুস্পষ্ট কমিট ইতিহাস (commit history) তৈরি করার জন্য নিয়ম-কানুনের একটি সহজ সেট প্রদান করে; যার উপর (কমিট ইতিহাসের) ভিত্তি করে পরবর্তিতে স্বয়ংক্রিয় সরঞ্জাম (tools) লেখা/তৈরি করা সহজ হয়। এই প্রচলণটি কমিট বার্তাগুলিতে করা বৈশিষ্ট্য, সংশোধন এবং উল্লেখযোগ্য পরিবর্তনগুলির বর্ণনার ধরণ দিয়ে [SemVer (Sementic Versioning)](http://semver.org)-এর সাথে সমন্বিত।
কমিট বার্তার ক্ষেত্রে নিম্নরূপ গঠন অনুসরণ করা উচিতঃ
---
বাংলায়ঃ
```
<ধরণ>[ঐচ্ছিক প্রসার]: <বিবরণ/কমিট শিরোনাম>
[ঐচ্ছিক বিস্তারিত তথ্য]
[ঐচ্ছিক উপসংহার/পরিশেষ]
```
ইংরেজিতেঃ
```
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
```
---
<br />
আপনার প্রকল্পের সাথে সম্পর্কিতদের কাছে নতুন কাজ বা পরিবর্তনের অভিপ্রায় জানাতে কমিট-এ নিম্নলিখিত কাঠামোগত উপাদান থাকবেঃ
1. **fix:** ফিক্স মানে সংশোধন। _ধরণ (type)_ `fix` প্রকৃতির একটি কমিট আপনার কোডবেসে একটি ত্রুটি সংশোধন করা বোঝায় (এটি শব্দার্থিক সংস্করণে (Semantic Versioning) [`PATCH`](http://semver.org/#summary)-এর সাথে সম্পর্কযুক্ত)।
1. **feat:** এটি feature-এর সংক্ষিপ্ত রূপ, এর মানে বৈশিষ্ট্য। _ধরণ (type)_ `feat`-এর একটি কমিট আপনার কোডবেসে একটি নতুন বৈশিষ্ট্য প্রবর্তন করা বোঝায় (এটি শব্দার্থিক সংস্করণে [`MINOR`](http://semver.org/#summary)-এর সাথে সম্পর্কযুক্ত)।
1. **BREAKING CHANGE:** একটি কমিট যার পরিশেষে (footer) `BREAKING CHANGE:` রয়েছে, অথবা ধরণ/প্রসার (type/scope) পরে একটি `!` যুক্ত রয়েছে, তার দ্বারা উল্লেখযোগ্য হারে কোড বা API পরিবর্তন করা হয়েছে বোঝায় (এটি শব্দার্থিক সংস্করণে [`MAJOR`](http://semver.org/#summary)-এর সাথে সম্পর্কিত)। একটি BREAKING CHANGE যেকোনো কমিট _ধরণ (type)_-এর অংশ হতে পারে।
1. `fix:` এবং `feat:` ছাড়া অন্যান্য _ধরণ_ বা _types_ অনুমোদিত, যেমন [@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:`, এবং অন্যান্য ধরণ ব্যবহারে উৎসাহিত করে।
1. [গিট ট্রেলার ফর্ম্যাট](https://git-scm.com/docs/git-interpret-trailers) এর অনুরূপ প্রচলন অনুসরণ করে `BREAKING CHANGE: <description>` (`উল্লেখ্যযোগ্য পরিবর্তন: <বিবরণ>`) ছাড়াও অন্য _পরিশেষ_ বা _footers_ প্রদান করা যেতে পারে।
অতিরিক্ত ধরণসমূহ (types) প্রচলিত কমিটসমূহের নির্দিষ্টকরণ (রীতি) দ্বারা বাধ্যতামূলক নয়, এবং শব্দার্থিক সংস্করণে এর কোন অন্তর্নিহিত প্রভাব নেই (যদি না তা একটি উল্লেখযোগ্য পরিবির্তন (BREAKING CHANGE) অন্তর্ভুক্ত করে)।
<br /><br />
অতিরিক্ত প্রাসঙ্গিক তথ্য প্রদানের জন্য একটি কমিটের ধরণ/প্রকার (type) -এর পাশে একটি প্রসার তথ্য (scope) প্রদান করা যেতে পারে এবং তা `()` বন্ধনীর মধ্যে থাকে। গঠন হবে এরকম -> `ধরণ(প্রসার): কমিট শিরোনাম..`। উদাহরণঃ `feat(parser): add ability to parse arrays`; এর দ্বারা বোঝানো হচ্ছে কোডবেসের 'parser' অংশে বৈশিষ্ট হিসেবে অ্যারে পার্স করার সক্ষমতা যোগ করা হয়েছে।
## উদাহরণ
### বিবরণ এবং উল্লেখযোগ্য পরিবর্তন (BREAKING CHANGE) পরিশেষ (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
```
### উল্লেখযোগ্য পরিবর্তনের (BREAKING CHANGE) প্রতি দৃষ্টি আকর্ষণ করতে `!` দিয়ে কমিট বার্তা
```
feat!: send an email to the customer when a product is shipped
```
### উল্লেখযোগ্য পরিবর্তনের (BREAKING CHANGE) প্রতি দৃষ্টি আকর্ষণ করতে প্রসার (scope) এবং `!` সহ কমিট বার্তা
```
feat(api)!: send an email to the customer when a product is shipped
```
### পরিশেষে (footer) উল্লেখযোগ্য পরিবর্তন (BREAKING CHANGE) এবং `!` , উভয় সহ কমিট বার্তা
```
feat!: drop support for Node 6
BREAKING CHANGE: use JavaScript features not available in Node 6.
```
### বিস্তারিত তথ্য (body) ছাড়াই কমিট বার্তা
```
docs: correct spelling of CHANGELOG
```
### প্রসার (scope) সহ কমিট বার্তা
```
feat(lang): add Bangla 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 ২১১৯](https://www.ietf.org/rfc/rfc2119.txt) অনুসারে অর্থ প্রকাশ করে।
1. কমিটসমূহ MUST (অবশ্যই) একটি ধরণের (type) উপসর্গ (prefix) দিয়ে শুরু করতে হবে, যার মধ্যে একটি বিশেষ্য (noun), `feat`, `fix`, ইত্যাদি থাকবে, এরপর OPTIONAL (ঐচ্ছিক) প্রসার (scope), OPTIONAL (ঐচ্ছিক) `!`, এবং প্রয়োজনীয় টার্মিনাল কোলন (`:`) এবং স্পেস REQUIRED (থাকতে হবে)।
1. `feat` ধরণটি MUST (অবশ্যই) ব্যবহার করতে হবে যখন কোনো কমিট আপনার অ্যাপ্লিকেশন বা লাইব্রেরিতে একটি নতুন বৈশিষ্ট্য (feature) যুক্ত করে।
1. `fix` ধরণটি MUST (অবশ্যই) ব্যবহার করতে হবে যখন কোনো কমিট আপনার অ্যাপ্লিকেশনে একটি ত্রুটি সংশোধন (fix) করে।
1. ধরণের (type) এর সাথে একটি প্রসার (scope) প্রদান করা (MAY) যেতে পারে। একটি প্রসার (scope) MUST (অবশ্যই) একটি বিশেষ্য (noun) নিয়ে গঠিত হবে যা কোডবেসের একটি অংশকে ইঙ্গিত করবে এবং `()` বন্ধনী দ্বারা বেষ্টিত থাকবে। উদাহরণস্বরূপ, কোডবেসের parser অংশে একটি সংশোধনমূলক কমিট করতে আমরা ব্যবহার করবো `fix(parser):`।
1. ধরণ/প্রসার (type/scope) উপসর্গ (prefix) এর সাথে কোলন এবং স্পেস (`: `) এর পরপরই MUST (অবশ্যই) একটি বিবরন (description) থাকতে হবে।
বিবরণটি কোডে পরিবর্তনের সংক্ষিপ্ত সারাংশ হবে। গঠণঃ `<ধরণ/(প্রসার)>: <বিবরণ>`। উদাহরণস্বরূপ, `fix: array parsing issue when multiple spaces were contained in string.`
1. সংক্ষিপ্ত বিবরণের (description) পরে একটি কমিটে দীর্ঘ বিস্তারিত তথ্য (body) প্রদান করা (MAY) যেতে পারে, যা কোডের পরিবর্তন সম্পর্কে অতিরিক্ত প্রাসঙ্গিক তথ্য প্রদান করে। বিস্তারিত তথ্য (body) অবশ্যই (MUST) বিবরণের পরে একটি ফাঁকা লাইন রেখে শুরু করতে হবে।
1. কমিটে বিস্তারিত তথ্য (body) সীমাবদ্ধ নয় এবং যেকোন সংখ্যক নতুন লাইনে বিভক্ত অনুচ্ছেদ নিয়ে গঠিত (MAY) হতে পারে।
1. বিস্তারিত তথ্য (body) -এর পরে একটি ফাঁকা লাইন রেখে এক বা একাধিক পরিশেষ (footers) থাকতে (MAY) পারে। প্রতিটি পরিশেষে MUST (অবশ্যই) একটি শব্দ টোকেন থাকবে, তারপর একটি `:<স্পেস>` বা `<স্পেস>#` বিভাজক থাকবে, তারপর একটি স্ট্রিং মান থাকবে (এটি [গিট ট্রেলার প্রচলণ](https://git-scm.com/docs/git-interpret-trailers) দ্বারা অনুপ্রাণিত)।
1. একটি পরিশেষের (footer's) টোকেন হিসেবে হোয়াইটস্পেস অক্ষরের জায়গায় MUST (অবশ্যই) `-` ব্যবহার করতে হবে, যেমন, `Acked-by` (এটি বিস্তারিত তথ্য (body) সমৃদ্ধ্ বহু-অনুচ্ছেদ থেকে পরিশেষ বিভাগকে আলাদা করতে সাহায্য করে)। তবে `BREAKING CHANGE`-এর জন্য তা ব্যতিক্রম রাখা হয়েছে, যা টোকেন হিসেবেও ব্যবহার করা (MAY) যেতে পারে।
1. একটি পরিশেষের মানের মধ্যে স্পেস এবং নতুন লাইন থাকতে (MAY) পারে, এবং পরবর্তী যুক্তিসিদ্ধ পরিশেষ (footer) টোকেন/বিভাজক জোড়া পরিলক্ষিত হলে পার্সিং (parsing) MUST (অবশ্যই) বন্ধ করতে হবে।
1. উল্লেখযোগ্য পরিবর্তনগুলি MUST (অবশ্যই) কমিটের প্রকার/প্রসার (type/scope) উপসর্গে (prefix) বা পরিশেষে একটি লিপিভুক্ত (entry) হিসাবে নির্দেশিত হতে হবে।
1. পরিশেষ (footer) হিসেবে অন্তর্ভুক্ত করা হলে, একটি উল্লেখযোগ্য পরিবর্তন (breaking change) এর মধ্যে MUST (অবশ্যই) বড় হাতে লেখা 'BREAKING CHANGE' থাকতে হবে, তারপর যথাক্রমে একটি কোলন, স্পেস এবং বিবরণ। যেমন, `BREAKING CHANGE: environment variables now take precedence over config files`।
1. প্রকার/প্রসার (type/scope) উপসর্গ (prefix) অন্তর্ভুক্ত থাকলে, উল্লেখযোগ্য পরিবর্তনসমূহ নির্দেশ করার জন্য `:` এর ঠিক আগে MUST (অবশ্যই) একটি `!` ব্যবহার করতে হবে। যদি `!` ব্যবহার করা হয়, তবে পরিশেষ (footer) বিভাগ থেকে `BREAKING CHANGE:` বাদ দেওয়া যেতে (MAY) পারে এবং উল্লেখযোগ্য পরিবর্তন বর্ণনা করতে কমিট বিবরণ (description) ব্যবহার (SHALL) করা হবে।
1. `feat` এবং `fix` ছাড়াও অন্যান্য ধরণ আপনার কমিট বার্তাগুলিতে ব্যবহার করা (MAY) যেতে পারে, যেমন, `docs: update ref docs.`।
1. তথ্যের একক যা প্রচলিত কমিটসমূহ (Conventional Commits) তৈরি করে তা বাস্তবায়নকারীদের দ্বারা কোন ভাবেই কেস সংবেদনশীল (case sensitive) হিসাবে ব্যবহার (MUST NOT) করা যাবে না, তবে 'BREAKING CHANGE' এর ক্ষেত্রে ব্যতিক্রম যা MUST (অবশ্যই) বড় হাতের হতে হবে।
1. পরিশেষে টোকেন হিসেবে ব্যবহৃত হলে 'BREAKING-CHANGE' অবশ্যই (MUST) 'BREAKING CHANGE'-এর সমার্থক হতে হবে।
## কেন প্রচলিত কমিটসমূহের (নির্দিষ্টকরণ রীতি) ব্যবহার করবেন
* স্বয়ংক্রিয়ভাবে পরিবর্তনধারা (CHANGELOG) তৈরি করতে।
* স্বয়ংক্রিয়ভাবে শব্দার্থিক (semantic) সংস্করণ নির্ধারণ বা পরিবর্তন করতে (কমিটসমূহের ধরণের উপর ভিত্তি করে)।
* পরিবর্তনের প্রকৃতি সহকর্মী, জনসাধারণ এবং অন্যান্য অংশীদারদের মধ্যে যথাযথ ভাবে প্রকাশ করতে।
* প্রস্তুত (build) এবং প্রকাশ (publish) প্রক্রিয়া চালু করতে।
* একটি অধিকতর কাঠামোবদ্ধ কমিট ইতিহাস অন্বেষণ করার মধ্য দিয়ে আপনার প্রকল্পে অন্য মানুষদেরকে অবদান রাখাকে সহজ করতে।
## সচরাচর জিজ্ঞাসিত প্রশ্নাবলি
> বৈষয়িক সুবিধার জন্য প্রশ্নাবলির বাংলা শিরোনামের নিচে ইংরেজি প্রশ্নও রাখা হয়েছে। (এক্ষেত্রে আক্ষরিক অর্থ উপেক্ষিত)
### প্রাথমিক উন্নয়ন (development) পর্যায়ে আমি কীভাবে কমিট বার্তাগুলির ব্যবস্থা নিবো?
How should I deal with commit messages in the initial development phase?
আমরা সুপারিশ করি যে আপনি এমনভাবে এগিয়ে যান যেন আপনি ইতিমধ্যে পণ্যটি প্রকাশ (release) করে ফেলেছেন। সাধারণত *কেউ*, এমনকি আপনার সহকর্মীরা যদি আপনার সফ্টওয়্যার ব্যবহার করেন, তারা জানতে চাইবেন কি সমাধান হয়েছে, কিসে সমস্যা আছে ইত্যাদি।
### কমিট শিরোনামের (লিখার) ধরণ কি বড় হাতের বা ছোট হাতের?
Are the types in the commit title uppercase or lowercase?
যেকোন ধরণ (case) ব্যবহার করা যেতে পারে, তবে প্রকল্প জুড়ে সামঞ্জস্য বজায় রাখা ভালো।
### কমিট যদি একাধিক কমিট ধরনের (types) সাথে সঙ্গতিপূর্ণ হয় তাহলে আমি কী করব?
What do I do if the commit conforms to more than one of the commit types?
সম্ভব হলে পিছনে যান এবং একাধিক কমিট করুন। Conventional Commits বা প্রচলিত কমিটসমূহের (নির্দিষ্টকরণ রীতির) উপকারের অংশ বা সক্ষমতা হলো এটি আমাদেরকে আরও সংগঠিত কমিট এবং পুল অনুরোধ (PR) করতে উৎসাহিত করে।
### এটা কি দ্রুত উন্নয়ন এবং দ্রুত পুনরাবৃত্তিকে নিরুৎসাহিত করে না?
Doesn’t this discourage rapid development and fast iteration?
এটি আপনাকে দীর্ঘমেয়াদে একাধিক প্রকল্প জুড়ে বিভিন্ন অবদানকারীদের সাথে নিয়ে দ্রুত অগ্রসর হতে সাহায্য করে, কিন্তু অসংগঠিত উপায়ে দ্রুত অগ্রসর হতে নিরুৎসাহিত করে।
### প্রচলিত কমিটসমূহ (Conventional Commits) কি ডেভেলপারদের জন্য কমিটের ধরন সীমাবদ্ধ করতে পারে যেহেতু তারা প্রদত্ত ধরনগুলি নিয়েই চিন্তা করবে?
Might Conventional Commits lead developers to limit the type of commits they make because they'll be thinking in the types provided?
Conventional Commits বা প্রচলিত কমিটসমূহ (নির্দিষ্টকরণ রীতি) আমাদেরকে নির্দিষ্ট ধরনের আরও অধিক কমিট ব্যবহার করতে উৎসাহিত করে। তাছাড়াও, প্রচলিত কমিটসমূহের নমনীয়তা আপনার দলকে তাদের নিজস্ব ধরণ (types) ব্যবহার করতে এবং সময়ের সাথে সাথে সেই ধরণ বা প্রকারগুলিকে পরিবর্তন করার অনুমতি দেয়৷
### এটি কিভাবে সেমভারের (SemVer) সাথে সম্পর্কিত?
How does this relate to SemVer?
`fix` কমিট ধরণকে `PATCH` হিসেবে অনুবাদ করা যায়। `feat` ধরনের কমিটকে `MINOR` হিসেবে অনুবাদ করা যায়। কমিটসমূহে `BREAKING CHANGE` কমিটকে, ধরণ (type) নির্বিশেষে, `MAJOR` হিসেবে অনুবাদ করা যায়।
### আমি কীভাবে আমার এক্সটেনশনগুলিকে প্রচলিত কমিটসমূহের নির্দিষ্টকরণ রীতিতে সংস্করণ করব, যেমন `@forhadakhan/conventional-commit-spec`?
How should I version my extensions to the Conventional Commits Specification, e.g. `@forhadakhan/conventional-commit-spec`?
আমরা এই নির্দিষ্টকরণ রীতিতে আপনার নিজস্ব এক্সটেনশন প্রকাশ করতে [SemVer](http://semver.org/#summary) ব্যবহার করার পরামর্শ দিচ্ছি (এবং এই এক্সটেনশনগুলি তৈরি করতে আপনাকে উত্সাহিত করছি!)
### আমি ভুলবশত যদি ভুল কমিট ধরণ ব্যবহার করে ফেলি তাহলে কি করব?
What do I do if I accidentally use the wrong commit type?
#### যখন আপনি রীতির মধ্যে থাকা একটি ধরন (type) ব্যবহার করেন কিন্তু তা সঠিক ধরন (type) নয়, উদাহরণস্বরূপ `feat` এর পরিবর্তে `fix` ব্যবহার।
ভুল কমিট একত্রিত (merge) বা প্রকাশ (release) করার আগে, `git rebase -i` ব্যবহার করে কমিট ইতিহাস সম্পাদনা বা পরিবর্তন করতে পারেন। প্রকাশিত (released) হয়ে গেলে, আপনি কোন টুল এবং প্রক্রিয়া ব্যবহার করেছেন তা অনুযায়ী সংশোধন প্রক্রিয়া ভিন্ন হবে।
#### যখন আপনি রীতির বাইরে কোনো ধরন (type) ব্যবহার করেন, উদাহরণস্বরূপ `feat` এর পরিবর্তে `feet` ব্যবহার।
সবচেয়ে খারাপ পরিস্থিতিতে, যদি একটি কমিট 'প্রচলিত কমিটসমূহের নির্দিষ্টকরণ রীতি'-এর শর্ত পূরণ না করে তবে এখানেই যে দুনিয়া শেষ, বিষয়টি এমন নয়। কেবলমাত্র ঐ প্রকল্পে 'প্রচলিত কমিটসমূহের নির্দিষ্টকরণ রীতি'-এর উপর ভিত্তি করে কোন স্বয়ংক্রিয় প্রক্রিয়া ব্যবহৃত হলে, তাতে ভুলকৃত কমিট-টি চিহ্নিত হবে না।
### আমার সমস্ত অবদানকারীদের কি প্রচলিত কমিটসমূহের নির্দিষ্টকরণ রীতি ব্যবহার করতে হবে?
Do all my contributors need to use the Conventional Commits specification?
না! যদি আপনি গিটের স্কোয়াশ ভিত্তিক কর্মপ্রবাহ (squash-based workflow) ব্যবহার করেন, তবে প্রধান রক্ষকরা একত্রিত (merge) হওয়ার সময় কমিট বার্তাগুলিকে পরিষ্কার করতে পারেন — এটি সাধারণ অবদানকারী বা কমিটকারীদের-কে কাজের কোনো চাপ দেয় না।
এর জন্য একটি প্রচলিত কর্মপ্রবাহ হল আপনার গিট সিস্টেমে স্বয়ংক্রিয়ভাবে পুল (pull) অনুরোধ থেকে কমিটগুলি স্কোয়াশ করা এবং প্রধান রক্ষণাবেক্ষণকারীকে মার্জ করার সময় যথাযথ গিট কমিট বার্তা প্রবেশ করার জন্য একটি ফর্ম উপস্থাপন করা।
### কিভাবে প্রচলিত কমিটসমূহ প্রত্যাবর্তন কমিট পরিচালনা করে?
How does Conventional Commits handle revert commits?
> রিভার্ট বা প্রত্যাবর্তন মানে পূর্বের কোন অবস্থায় ফেরত যাওয়া।
কোড প্রত্যাবর্তন (revert) করা জটিল হতে পারে: আপনি কি একাধিক কমিট প্রত্যাবর্তন করছেন? যদি আপনি একটি বৈশিষ্ট্য প্রত্যাবর্তন করেন, তাহলে কি পরবর্তী প্রকাশ (release) একটি পূর্ণ প্রকাশ বা উন্মোচন-এর পরিবর্তে একটি patch (সহজ কথায় 'জোড়া/তালি') হওয়া উচিত?
প্রচলিত কমিটসমূহ (Conventional Commits) প্রত্যাবর্তন আচরণকে সংজ্ঞায়িত করার জন্য কোনো সুস্পষ্ট নীতি প্রয়োগের প্রচেষ্টা করে না। বরং _types_ এবং _footers_-এর নমনীয়তা ব্যবহার করে প্রত্যাবর্তন পরিচালনার জন্য যুক্তির বিকাশ করতে এটিকে লেখকদের (coders) উপর ছেড়ে দেয়।
তবে একটি সুপারিশ হলো ধরণ (type) হিসেবে `revert` ব্যবহার করা এবং যে কমিটকে প্রত্যাবর্তন করা হচ্ছে তার SHA-কে উল্লেখ করে একটি পরিশেষ (footer) ব্যবহার করা। যেমনঃ
```
revert: let us never again speak of the noodle incident
Refs: 676104e, a215868
```
================================================
FILE: content/v1.0.0/index.de.md
================================================
---
draft: false
aliases: ["/de/"]
---
# Konventionelle Commits 1.0.0
## Zusammenfassung
Die Spezifikation für konventionelle Commits ist eine einfache Konvention, die auf Commit-Nachrichten aufbaut.
Sie enthält einfache Regeln zum Erstellen einer expliziten Commit-Historie;
das macht es einfacher, automatisierte Tools dazu zu schreiben.
Diese Konvention knüpft an [SemVer](http://semver.org/lang/de/) an,
indem sie die Funktionen, Korrekturen und Änderungen beschreibt, die in Commit-Nachrichten vorgenommen wurden.
Die Commit-Nachricht sollte wie folgt aufgebaut sein:
---
```
<Typ>[optionaler Gültigkeitsbereich]: <Beschreibung>
[optionaler Textkörper]
[optionale Fußnoten]
```
---
<br />
Der Commit enthält die folgenden Strukturelemente, um den Benutzern Ihrer Bibliothek Ihre Absichten mitzuteilen:
1. **fix:** ein Commit des _Typs_ `fix` behebt einen Fehler in Ihrer Codebasis (dies entsprich einem [`PATCH`](http://semver.org/#summary) in semantischer Versionierung).
1. **feat:** ein Commit des _Typs_ `feat` führt eine neue Funktion in Ihrer Codebasis ein (dies entspricht einem [`MINOR`](http://semver.org/#summary) in semantischer Versionierung).
1. **BREAKING CHANGE:** ein Commit mit `BREAKING CHANGE:` in der Fußzeile, oder einem angehängten `!` nach dem Typ/Gültigkeitsbereich, führt tiefgreifende Änderungen an der API ein (dies entspricht einem [`MAJOR`](http://semver.org/#summary) in semantischer Versionierung).
Ein BREAKING CHANGE kann Teil eines Commits jeden _Typs_ sein.
1. Andere _Typen_ als `fix:` und `feat:` sind erlaubt, z. B. erlaubt [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (basierend auf [the Angular convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) `build:`, `chore:`,
`ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, und andere.
1. Andere _Fußzeilen_ als `BREAKING CHANGE: <Beschreibung>` können angegeben werden und folgen der Konvention ähnlich zum [git Trailer Format](https://git-scm.com/docs/git-interpret-trailers).
Zusätzliche Typen sind in der konventionellen Commit-Spezifikation nicht vorgeschrieben und haben keine impliziten Auswirkungen auf die semantische Versionierung (sofern sie keinen BREAKING CHANGE enthalten).
<br /><br />
Ein Gültigkeitsbereich kann zusammen mit einem Commit Typen angegeben werden, um weitere kontextuelle Informationen in Klammern zu geben, z. B. `feat(parser): add ability to parse arrays`.
## Beispiele
### Commit-Nachricht mit Beschreibung und Breaking Change Fußzeile
```
feat: allow provided config object to extend other configs
BREAKING CHANGE: `extends` key in config file is now used for extending other config files
```
### Commit-Nachricht mit `!` um auf einen Breaking Change aufmerksam zu machen
```
feat!: send an email to the customer when a product is shipped
```
### Commit-Nachricht mit Gültigkeitsbereich und `!` um auf einen Breaking Change aufmerksam zu machen
```
feat(api)!: send an email to the customer when a product is shipped
```
### Commit-Nachricht mit `!` als auch BREAKING CHANGE Fußzeile
```
feat!: drop support for Node 6
BREAKING CHANGE: use JavaScript features not available in Node 6.
```
### Commit-Nachricht ohne Textkörper
```
docs: correct spelling of CHANGELOG
```
### Commit-Nachricht mit Gültigkeitsbereich
```
feat(lang): add polish language
```
### Commit-Nachricht mit mehreren Absätzen und Fußzeilen
```
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
```
## Spezifikation
Die Schlüsselwörter "MUSS", "DARF NICHT", "ERFORDERLICH", "SOLL", "SOLL NICHT", "SOLLTE", "SOLLTE NICHT", "EMPFOHLEN", "KANN" und "OPTIONAL" dieses Dokuments werden wie in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) interpretiert.
1. Commits MÜSSEN einen Typen vorangestellt haben, der aus Nomen besteht, `feat`, `fix`, etc., gefolgt von einem OPTIONALEN Gültigkeitsbereich, OPTIONALEM `!` und einem ERFORDERLICHEN abschließenden Doppelpunkt und einem Leerzeichen.
1. Der Typ `feat` MUSS benutzt werden, wenn ein Commit neue Funktionalität zur Applikation oder Bibliothek hinzufügt.
1. Der Typ `fix` MUSS benutzt werden, wenn ein Commit eine Fehlerbehebung für die Applikation darstellt.
1. Ein Gültigkeitsbereich KANN nach einem Typen angegeben werden. Ein Gültigkeitsbereich MUSS aus einem Nomen in Klammern bestehen, das die betroffene Stelle im Code beschreibt, z. B. `fix(parser):`
1. Eine Beschreibung MUSS direkt auf den Doppelpunkt und ein Leerzeichen nach dem Typ/Gültigkeitsbereich folgen. Die Beschreibung ist eine kurze Zusammenfassung der Code-Änderungen, z. B. _fix: array parsing issue when multiple spaces were contained in string_.
1. Ein längerer Commit-Textkörper KANN nach der Kurzbeschreibung angegeben werden, um weitere kontextuelle Informationen über die Code-Änderungen zu geben. Der Textkörper MUSS nach eine Leerzeile nach der Beschreibung folgen.
1. Der Commit-Textkörper ist formlos und KANN aus einer beliebigen Anzahl an Absätzen bestehen, getrennt mit Zeilenumbrüchen.
1. Eine oder mehrere Fußzeilen KÖNNEN nach einer Leerzeile unter dem Textkörper angegeben werden. Jede Fußzeile MUSS aus einem Symbolwort bestehen, gefolgt von einem `:<leer>` oder `<leer>#` Trennzeichen und einem String-Wert (basierend auf der [git trailer convention](https://git-scm.com/docs/git-interpret-trailers)).
1. Symbolwörter MÜSSEN ein `-` statt eines Leerzeichens verwenden, z. B. `Acked-by` (dies hilft die Fußzeile von einem mehrzeiligen Textkörper zu unterscheiden). Eine Ausnahme bildet `BREAKING CHANGE`, was auch als Symbolwort benutzt werden KANN.
1. Der Wert einer Fußzeile KANN Leerzeichen und Zeilenumbrüche enthalten. Das Parsen MUSS beendet werden, wenn das nächste gültige Paar Fußzeilen-Symbolwort/Trennzeichen erkannt wird.
1. Breaking Changes MÜSSEN mit dem Typen-/Gültigkeitsbereichs-Präfix eines Commits angegeben werden oder als Eintrag in der Fußzeile.
1. Wenn ein Breaking Change als Fußzeile eingefügt wird, MUSS sie aus dem Großbuchstaben BREAKING CHANGE bestehen, gefolgt von einem Doppelpunkt, einem Leerzeichen und einer Beschreibung, z. B. _BREAKING CHANGE: environment variables now take precedence over config files_.
1. Wenn im Typen-/Gültigkeitsbereichs-Präfix enthalten, MÜSSEN Breaking Changes mit einem `!` direkt vor dem `:` angegeben werden. Wenn `!` benutzt wird KANN `BREAKING CHANGE:` aus der Fußzeile weggelassen werden und die Commit-Beschreibung SOLL benutzt werden um den Breaking Change zu beschreiben.
1. Andere Typen als `feat` und `fix` KÖNNEN in der Commit-Nachricht benutzt werden, z. B. _docs: updated ref docs._
1. Die Informationseinheiten, aus denen herkömmliche Commits bestehen, DÜRFEN von Implementierern NICHT mit Groß- und Kleinschreibung behandelt werden, mit Ausnahme von BREAKING CHANGE, bei dem es sich um Großbuchstaben handeln MUSS.
1. BREAKING-CHANGE MUSS mit BREAKING CHANGE synonym bleiben, wenn es als Symbolwort in der Fußzeile benutzt wird.
## Warum konventionelle Commits?
* Automatisch generierende CHANGELOGs.
* Automatisches Ermitteln einer semantischen Versionserhöhung (basierend auf den eingestellten Commit-Typen).
* Kommunikation der Art von Änderungen an Teamkollegen, die Öffentlichkeit und andere Stakeholder.
* Auslösen von Build- und Veröffentlichungsprozessen.
* Erleichtern Sie es Leuten, einen Beitrag zu Ihren Projekten zu leisten, indem Sie ihnen ermöglichen, einen strukturierteren Commit-Verlauf zu erkunden.
## FAQ
### Wie soll ich in der ersten Entwicklungsphase mit Commit-Nachrichten umgehen?
Wir empfehlen so zu verfahren, als ob Sie das Produkt bereits freigegeben hätten. In der Regel verwendet _jemand_ Ihre Software, auch wenn es sich nur um Ihre Kollegen handelt. Diese werden wissen wollen, was repariert ist, was kaputt geht usw.
### Sind Typen im Commit-Titel in Groß- oder Kleinbuchstaben?
Das ist ganz Ihnen überlassen, aber seien Sie dabei konsequent.
### Was mache ich, wenn der Commit mehr als einem der Commit-Typen entspricht?
Gehen Sie zurück und führen Sie nach Möglichkeit mehrere Commits durch. Ein Vorteil von konventionellen Commits ist, dass wir besser organisierte Commits und Pull Requests durchführen können.
### Verhindert dies nicht eine rasche Entwicklung und schnelle Iteration?
Es verhindert sich auf unorganisierte Weise schnell voranzubewegen. Es hilft Ihnen dabei, sich langfristig und schnell über mehrere Projekte mit unterschiedlichen Mitwirkenden hinweg zu bewegen.
### Könnten konventionelle Commits Entwickler dazu veranlassen, die Art der Commits zu begrenzen, die sie machen, weil sie in den zur Verfügung gestellten Typen denken werden?
Konventionelle Commits ermutigen uns, bestimmte Arten von Commits wie z. B. Fixes zu verwenden. Abgesehen davon ermöglicht die Flexibilität der konventionellen Commits Ihrem Team, eigene Typen zu entwickeln und diese Typen im Laufe der Zeit zu ändern.
### In welcher Beziehung steht dies zu SemVer?
Commits vom Typ `fix` sollten wie `PATCH` Releases behandelt werden. Commits vom Typ `feat` sollten wie `MINOR` Releases behandelt werden. Commits mit `BREAKING CHANGE` in den Commits sollten unabhängig vom Typ wie `MAJOR` Releases behandelt werden.
### Wie soll ich meine Erweiterungen der konventionellen Commit Spezifikation versionieren, z. B. `@jameswomack/conventional-commit-spec`?
Wir empfehlen die Verwendung von SemVer, um Ihre eigenen Erweiterungen für diese Spezifikation zu veröffentlichen (und begrüßen es, diese Erweiterungen vorzunehmen!)
### Was mache ich, wenn ich versehentlich den falschen Commit-Typ verwende?
#### Wenn Sie einen Typ verwendet haben, der der Spezifikation, aber nicht dem richtigen Typ entspricht, z. B. `fix` statt `feat`
Vor dem Mergen oder Freigeben des Fehlers wird empfohlen, mit `git rebase -i` die Commit Historie zu bearbeiten. Nach der Veröffentlichung ist die Bereinigung je nach den verwendeten Tools und Prozessen unterschiedlich.
#### Wenn Sie einen Typ verwendet haben, der *nicht* der Spezifikation entspricht, z. B. `feet` statt `feat`
Im schlimmsten Fall ist es nicht das Ende der Welt, wenn ein Commit nicht der konventionellen Commit Spezifikation entspricht. Dies bedeutet lediglich, dass der Commit nicht von Tools erfasst wird, die sich an die Spezifikation halten.
### Müssen alle meine Mitwirkenden die konventionelle Commit Spezifikation verwenden?
Nein! Wenn Sie einen Squash-basierten Workflow auf Git benutzen, können Lead Maintainer die Commit-Nachrichten beim Mergen bereinigen — ohne gelegentlichen Committern zusätzliche Arbeit aufzubürden.
Ein üblicher Workflow hierfür ist, dass Ihr Git-System automatisch Commits aus einem Pull Request squasht und dem Lead Maintainer ein Formular vorlegt, in dem er die richtige Git-Commit-Nachricht für den Merge eingibt.
### Wie geht Conventional Commits mit Revert Commits um?
Das Zurücksetzen von Code kann kompliziert sein: Setzen Sie mehrere Commits zurück? Wenn Sie ein Feature zurücksetzen, sollte die nächste Version stattdessen ein Patch sein?
Konventionelle Commits bemühen sich nicht explizit, das Wiederherstellungsverhalten zu definieren. Stattdessen überlassen wir es den Autoren, die Flexibilität von _Typen_ und _Fußzeilen_ zu nutzen, um ihre Logik für die Behandlung von Reverts zu entwickeln.
Eine Empfehlung wäre, den `revert` Typ und eine Fußzeile zu verwenden, die auf die zurückgesetzten Commit-SHAs verweist:
```
revert: let us never again speak of the noodle incident
Refs: 676104e, a215868
```
================================================
FILE: content/v1.0.0/index.es.md
================================================
---
draft: false
aliases: ["/es/"]
---
# Commits Convencionales 1.0.0
## Resumen
La especificación de Commits Convencionales es una convención ligera sobre los mensajes de commits.
Proporciona un conjunto sencillo de reglas para crear un historial de commits explícito;
lo que hace más fácil escribir herramientas automatizadas encima del historial.
Esta convención encaja con [SemVer](http://semver.org/lang/es/),
al describir en los mensajes de los commits las funcionalidades, arreglos, y cambios de ruptura hechos.
El mensaje del commit debe ser estructurado de la siguiente manera:
---
```
<tipo>[ámbito opcional]: <descripción>
[cuerpo opcional]
[nota(s) al pie opcional(es)]
```
---
<br />
El commit contiene los siguientes elementos estructurales, para comunicar la intención
a los consumidores de tu librería:
1. **fix:** un commit de _tipo_ `fix` corrige un error en la base del código (se correlaciona con [`PATCH`](http://semver.org/#summary) en el Versionado Semántico).
1. **feat:** un commit de _tipo_ `feat` introduce una nueva funcionalidad en la base del código (se correlaciona con [`MINOR`](http://semver.org/#summary) en el Versionado Semántico).
1. **BREAKING CHANGE:** un commit que contiene la nota al pie `BREAKING CHANGE:`, o que agrega un `!` después del tipo/ámbito, introduce un cambio de ruptura de API (se correlaciona con [`MAJOR`](http://semver.org/#summary) en el Versionado Semántico).
Un BREAKING CHANGE puede ser parte de commits de cualquier _tipo_.
1. _tipos_ distintos a `fix:` y `feat:` están permitidos, por ejemplo [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (basados en [la convención de Angular](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) que recomienda `build:`, `chore:`, `ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, y otros.
1. _notas al pie_ distintas de `BREAKING CHANGE: <descripción>` pueden ser añadidas y siguen una convención similar al [formato git trailer](https://git-scm.com/docs/git-interpret-trailers).
Tipos adicionales no son obligatorios en la especificación de Commits Convencionales,
y no tienen un efecto implícito en el Versionado Semántico (al menos que incluyan un BREAKING CHANGE).
<br /><br />
Un ámbito puede ser añadido al tipo de un commit, para proveer información adicional contextual y debe ser contenido entre paréntesis, ej., `feat(parser): add ability to parse arrays`.
## Ejemplos
### Mensaje de commit con descripción y cambio de ruptura en la nota al pie
```
feat: allow provided config object to extend other configs
BREAKING CHANGE: `extends` key in config file is now used for extending other config files
```
### Mensaje de commit con `!` para llamar la atención al cambio de ruptura
```
refactor!: drop support for Node 6
```
### Mensaje de commit con ambos `!` y BREAKING CHANGE en la nota al pie
```
refactor!: drop support for Node 6
BREAKING CHANGE: refactor to use JavaScript features not available in Node 6.
```
### Mensaje de commit sin cuerpo
```
docs: correct spelling of CHANGELOG
```
### Mensaje de commit con ámbito
```
feat(lang): added polish language
```
### Mensaje de commit con cuerpo multi-párrafo y múltiples notas al pie
```
fix: correct minor typos in code
see the issue for details
on typos fixed.
Reviewed-by: Z
Refs #133
```
## Especificación
Las palabras clave “DEBE” (“MUST”), “NO DEBE” (“MUST NOT”), “REQUERIDO” (“REQUIRED”),
“DEBERÁ” (“SHALL”), “NO DEBERÁ” (“SHALL NOT”), “DEBERÍA” (“SHOULD”),
“NO DEBERÍA” (“SHOULD NOT”), “RECOMIENDA” (“RECOMMENDS”), “PUEDE” (“MAY”) y
“OPCIONAL” (“OPTIONAL”) en este documento se deben interpretar como se describe
en [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
1. Los commits DEBEN iniciarse con un prefijo de tipo que consiste en un sustantivo, `feat`, `fix`, etc., seguido del ámbito OPCIONAL, `!`OPCIONAL, y dos puntos y un espacio REQUERIDO.
2. El tipo `feat` DEBE ser usado cuando un commit agrega una nueva funcionalidad a la aplicación o librería.
3. El tipo `fix` DEBE ser usado cuando el commit representa una corrección a un error en el código de la aplicación (bug).
4. Un ámbito PUEDE ser añadido después de un tipo. Un ámbito DEBE consistir en un sustantivo que describa una sección de la base del código encerrado entre paréntesis, ej., `fix(parser):`.
5. Una descripción DEBE ir inmediatamente después de los dos puntos y el espacio del prefijo de tipo/ámbito. La descripción es resúmen corto de los cambios realizados en el código, ej., _fix: array parsing issue when multiple spaces were contained in string._.
6. Un cuerpo de commit más extenso PUEDE agregarse después de la descripción corta, dando información contextual adicional acerca de los cambios en el código. El cuerpo DEBE iniciar después de una línea en blanco después de la descripción.
7. Un cuerpo de commit es de forma-libre y PUEDE consistir de cualquier número de párrafos separados por una nueva línea.
8. Una o más notas al pie PUEDEN ser añadidas una línea en blanco después del cuerpo. Cada nota al pie DEBE consistir de una palabra clave, seguida ya sea por un separador `:<espacio>` o `<espacio>#`, seguido por un valor cadena (string) (esto está inspirado por la [convención git trailer](https://git-scm.com/docs/git-interpret-trailers)).
9. Una palabra clave de una nota al pie DEBE usar `-` en lugar de caracteres de espacios en blanco, ej., `Acked-by` (esto ayuda a diferenciar la sección de la nota al pie de un cuerpo multi párrafo). Se hace una excepción para `BREAKING CHANGE`, que también PUEDE ser usada como palabra clave.
10. Una nota al pie PUEDE contener espacios y líneas en blanco, y el parseo DEBE terminar cuando se observe el siguiente separador/clave.
11. Los cambios de ruptura DEBEN ser indicados en el prefijo de tipo/ámbito de un commit, o como una entrada en la nota al pie.
12. Si se incluye como una nota al pie, un cambio de ruptura DEBE consistir del texto en mayúsculas BREAKING CHANGE, seguido de dos puntos, y una descripción, ej., _BREAKING CHANGE: environment variables now take precedence over config files_.
13. Si se incluye en el prefijo de tipo/ámbito, cambios de ruptura DEBEN ser indicados por un `!` inmediatamente después de `:`. Si `!` es usado, `BREAKING CHANGE:` PUEDE ser omitido de la sección de la nota al pie, y la descripción del commit DEBERÁ ser usada para describir el cambio de ruptura.
14. Tipos diferentes a `feat` y `fix` PUEDEN ser usados en los mensajes de commit, ej., _docs: updated ref docs._.
15. Las unidades de información que componen Commits Convencionales NO DEBEN ser tratados como implementadores sensitivos de caso, con la excepción de BREAKING CHANGE que DEBE ir en mayúsculas.
16. BREAKING-CHANGE DEBE ser sinónimo de BREAKING CHANGE, cuando se usa en una nota al pie.
## ¿Por qué usar Commits Convencionales?
* Generación automática de CHANGELOGs.
* Determinación automática de un salto de versión semántico (basado en los tipos de commits utilizados).
* Comunicar la naturaleza de los cambios a los demás integrantes del equipo, el público o cualquier otro interesado.
* Activar procesos de procesos y publicación.
* Hacer más fácil a otras personas contribuir al proyecto al permitirles explorar una historia de los commits más estructurada.
## FAQ (Preguntas Frecuentes)
### ¿Cómo puedo trabajar con los mensajes de los commits en la etapa inicial de desarrollo?
Recomendamos trabajar como si ya hubieras lanzado tu producto. Típicamente _alguien_, incluso si son tus compañeros desarrolladores, están usando tu software. Ellos querrán saber qué se ha arreglado, qué se ha dañado, etc.
### ¿Los tipos en los títulos de los commits están en mayúsculas o en minúsculas?
Se puede utilizar cualquiera, pero es mejor ser coherente.
### ¿Qué hago si el commit se ajusta a más de uno de los tipos de commit?
Regresa y haz múltiples commits de ser posible. Parte de los beneficios de los Commits Convencionales es la habilidad para hacer commits y PRs más organizados.
### ¿No desalienta esto el desarrollo y la iteración rápida?
Desalienta moverse rápido de una forma desorganizada. Te ayuda a ser capaz de moverte rápido a largo plazo a través de proyectos con una gran variedad de contribuidores.
### ¿Pueden los Commits Convencionales llevar a los desarrolladores a limitar el tipo de commits que hacen ya que estarán pensando en los tipos previstos?
Los Commits Convencionales nos animan a hacer más de ciertos tipos de commits como _fixes_. Adicionalmente, la flexibilidad de los Commits Convencionales le permite a tu equipo generar sus propios tipos y cambiarlos a lo largo del tiempo.
### ¿Cómo se relaciona esto con SemVer?
El tipo de commit `fix` se traduce a un cambio de versión `PATCH`. El tipo de commit `feat` se traduce a un cambio de versión `MINOR`. Commits con el texto `BREAKING CHANGE`, sin importar su tipo, se traducen a un cambio de versión `MAJOR`.
### ¿Cómo debo versionar mis extensiones a la especificación de Commits Convencionales, e.g. `@jameswomack/conventional-commit-spec`?
Recomendamos usar SemVer para liberar tu propia extensión a esta especificación (¡Y te animamos a hacer esta extensión!)
### ¿Qué debo hacer si por accidente uso un tipo de commit equivocado?
#### Cuando utilizaste un tipo que es de la especificación pero del tipo correcto, e.g. `fix` en lugar de `feat`
Antes de combinar o liberar el error, recomendamos usar `git rebase -i` para editar el historial de los commits. Después de que se ha liberado, la limpieza será distinta de acuerdo a las herramientas y procesos que hayas utilizado.
#### Cuando usas un tipo que no está en la especificación, ej. `feet` en lugar de `feat`
En el peor de los escenarios, no es el fin del mundo si aparece un commit que no cumple con las especificaciones de los Commits Convencionales. Simplemente significa que el commit será ignorado por las herramientas que se basen en esta especificación.
### ¿Deben todos los que contribuyen a mi proyecto usar esta especificación?
¡No! Si usas un flujo de trabajo basado en `squash` los líderes del proyecto pueden limpiar el mensaje en el momento en que se incorpora, sin agregar cargas adicionales a quienes contribuyen casualmente. Un flujo de trabajo común para esto es configurar tu sistema de git para que haga el `squash` de manera automática de un pull request y presente al líder del proyecto un formulario para que ingrese el mensaje de commit correcto al momento de hacer el merge.
### ¿Cómo maneja Commits Convencionales el revertir código?
Revertir código puede ser complicado: ¿Estás revirtiendo múltiples commits? ¿Si reviertes una funcionalidad, debería ser la siguiente versión un _patch_?
Commits Convencionales no hace un esfuerzo explícito para definir el comportamiento al revertir. En lugar de eso le dejamos a los autores de las herramientas la flexibilidad de los _tipos_ y _notas al pie_ para desarrollar la lógica para manejar los _reverts_.
Una recomendación es usar el tipo `revert`, y una nota al pie que haga referencia a los commit SHAs que son revertidos:
```
revert: let us never again speak of the noodle incident
Refs: 676104e, a215868
```
================================================
FILE: content/v1.0.0/index.fr.md
================================================
---
draft: false
aliases: ["/fr/"]
---
# Commits Conventionnels 1.0.0
## Résumé
La spécification de Commits Conventionnels est une convention basique pour des messages de commit propres.
Elle fournit un ensemble simple de règles pour créer un historique de commit explicite,
ce qui facilite l'écriture d'outils automatisés.
Cette convention suit [SemVer](http://semver.org/lang/fr/),
en décrivant les fonctionnalités, les correctifs et les modifications importantes apportées aux messages de commit.
Le message du commit doit être structuré comme suit :
---
```
<type>[étendue optionnelle]: <description>
[corps optionnel]
[pied optionnel]
```
---
<br />
Le commit contient les éléments structurels suivants, permettant de communiquer à l’intention des
consommateurs de votre API :
1. **fix:** un commit de _type_ `fix` corrige un bogue dans le code (cela est en corrélation avec [`PATCH`](http://semver.org/#summary)
en gestion sémantique de versions).
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 gestion sémantique de versions).
1. **BREAKING CHANGE:** un commit qui contient dans son _pied_ le mot-clé `BREAKING CHANGE:`,
ou dont le _type_/_étendue_ est suffixé d'un `!`, introduit une rupture de compatibilité dans l'API
(cela est en corrélation avec [`MAJOR`](http://semver.org/#summary) en gestion sémantique de versions).
Un BREAKING CHANGE peut faire partie des commits de n'importe quel _type_.
1. Les _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/22b96b9/CONTRIBUTING.md#-commit-message-guidelines))
recommande `build:`, `chore:`, `ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, etc.
1. Les _pieds_ autres que `BREAKING CHANGE: <description>` peuvent être fournis et suivre une convention similaire à
[git trailer format](https://git-scm.com/docs/git-interpret-trailers).
Les types supplémentaires ne sont pas prescrits par la spécification de Commits Conventionnels et n'ont aucun effet implicite dans la gestion des versions sémantiques (à moins qu'ils ne comportent un BREAKING CHANGE).
<br /><br />
Une _étendue_ peut être fournie au type d'un commit pour fournir des informations contextuelles supplémentaires. Elle est indiquée entre parenthèses, par exemple, `feat(parser): add the ability to parse arrays`.
## Exemples
### Message du commit avec description et breaking change dans le _pied_
```
feat: allow provided config object to extend other configs
BREAKING CHANGE: `extends` key in config file is now used for extending other config files
```
### Message du commit avec `!` qui attire l'attention sur un BREAKING CHANGE
```
feat!: send an email to the customer when a product is shipped
```
### Message du commit avec _étendue_ et `!` qui attire l'attention sur un BREAKING CHANGE
```
feat(api)!: send an email to the customer when a product is shipped
```
### Message du commit avec `!` et BREAKING CHANGE dans le _pied_
```
feat!: drop support for Node 6
BREAKING CHANGE: use JavaScript features not available in Node 6.
```
### Message du commit sans _corps_
```
docs: correct spelling of CHANGELOG
```
### Message du commit avec _étendue_
```
feat(lang): add polish language
```
### Message du commit avec plusieurs paragraphes dans le _corps_, et plusieurs _pieds_
```
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
```
## Spécification
Les mots clés ”DOIT” (“MUST”), “NE DOIT PAS” (“MUST NOT”), “REQUIS” (“REQUIRED”), “DEVRA” (“SHALL”),
“NE DEVRA PAS” (“SHALL NOT”), “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. Un commit DOIT être préfixé par un _type_, qui consiste en un nom (`feat`, `fix`, etc.), suivi
par une _étendue_ FACULTATIVE, un `!` FACULTATIF, et de deux-points et d'un espace REQUIS.
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. Une _étendue_ PEUT être fournie après un _type_. Une _étendue_ DOIT être un nom décrivant
une section du code, et être encadrée par des parenthèses, par exemple, `fix(parser):`
1. Une _description_ DOIT suivre immédiatement les deux-points et l'espace après le préfixe _type_/_étendue_.
La description est une brève description des modifications du code, par exemple,
_fix: array parsing issue when multiple spaces were contained in string_.
1. Un _corps_ de commit PEUT être fourni après la description courte, fournissant des informations contextuelles
supplémentaires sur les modifications du code. Le _corps_ DOIT commencer par une ligne vide après la _description_.
1. Un _corps_ est libre et PEUT se composer d'un nombre quelconque de paragraphes séparés par une nouvelle ligne.
1. Un ou plusieurs _pieds_ PEUVENT être fournis avec une ligne blanche après le _corps_. Chaque _pied_ DOIT se composer
d'un mot-clé, suivi par `:<space>` ou `<space>#`, suivi d'une chaine de caractère (d'après
[git trailer convention](https://git-scm.com/docs/git-interpret-trailers)).
1. Un mot-clé de _pied_ DOIT utiliser `-` au lieu des espaces, par exemple, `Acked-by` (cela permet de différencier la
section de _pied_ d'un _corps_ de plusieurs paragraphes). Une exception est faite pour `BREAKING CHANGE`, qui PEUT
aussi être utilisé comme un mot-clé.
1. La valeur d'un _pied_ PEUT contenir des espaces et des nouvelles lignes, et l'analyse grammaticale DOIT se terminer
lorsqu'une nouvelle paire mot-clé / séparateur de _pied_ valide est trouvée.
1. Une _rupture de compatibilité_ DOIT être indiquée soit dans le préfixe _type_/_étendue_ d'un commit, soit comme une
entrée dans le _pied_.
1. Si elle est incluse comme _pied_, une _rupture de compatibilité_ DOIT être écrite en majuscules : `BREAKING CHANGE`,
suivi par deux-points, espace, et une description, par exemple,
_BREAKING CHANGE: environment variables now take precedence over config files_.
1. Si elle est incluse dans le préfixe _type_/_étendue_, une _rupture de compatibilité_ DOIT être indiquée par un
`!` immédiatement avant le `:`. Si `!` est utilisé, `BREAKING CHANGE:` PEUT être omis de la section de _pied_,
et la _description_ du commit DEVRA être utilisée pour décrire la _rupture de compatibilité_.
1. Un _type_ autre que `feat` et `fix` PEUT être utilisé, par exemple, _docs: updated ref docs._
1. Les unités d’information qui composent Commits Conventionnels NE DOIVENT PAS être traitées comme sensibles à la casse
par les développeurs, à l'exception de BREAKING CHANGE qui DOIT être en majuscules.
1. BREAKING-CHANGE DOIT être synonyme de BREAKING CHANGE, lorsqu'il est utilisé comme mot-clé dans un _pied_.
## Pourquoi utiliser Commits Conventionnels
* Générer automatiquement des CHANGELOGs.
* Déterminer automatiquement un changement de version sémantique (en fonction des types de commits inclus).
* Communiquer la nature des changements aux membres de l'équipe, au public et aux autres parties prenantes.
* Déclencher des processus de génération et de publication.
* Faciliter la contribution des personnes à vos projets en leur permettant d’explorer un historique de commit plus structuré.
## FAQ
### Comment dois-je gérer les messages de commit dans la phase de développement initiale ?
Nous vous recommandons de procéder comme si vous aviez déjà publié un produit. Généralement *quelqu'un*, même si ce sont
vos collègues développeurs de logiciels, utilise votre logiciel. Il voudra savoir ce qui est corrigé, ce qui casse, etc.
### Les types dans le titre des commits sont-ils en majuscules ou en minuscules ?
N'importe quelle casse (majuscule ou minuscule) 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 ?
Revenez en arrière et faites plusieurs commits autant que possible. Une partie des avantages de Commits Conventionnels
réside dans sa capacité à nous inciter à créer des commits et des PR plus organisés.
### Est-ce que cela ne décourage pas le développement rapide et l’itération rapide ?
Cela décourage les commits rapides et désorganisés. Cela vous aide à être en mesure d'évoluer rapidement et à long terme
dans plusieurs projets avec des contributeurs variés.
### Les Commits Conventionnels pourraient-ils amener les développeurs à limiter le type d’engagement qu’ils effectuent car ils réfléchiront aux types fournis ?
Les Commits Conventionnels nous encouragent à utiliser davantage certains types de commits, tels que les correctifs.
En dehors de cela, la flexibilité des Commits Conventionnels permet à votre équipe de créer ses propres types et de les modifier
au fil du temps.
### Quel est le lien avec SemVer ?
Les commits de type `fix` doivent être traduits en versions `PATCH`.
Les commits de type `feat` doivent être traduits en versions `MINOR`.
Les commits avec `BREAKING CHANGE` dans les commits, quel que soit leur _type_, doivent être traduits en versions `MAJOR`.
### Comment dois-je mettre à jour mes extensions de la spécification de Commits Conventionnels, par exemple `@jameswomack/conventionnel-commit-spec` ?
Nous vous recommandons d'utiliser SemVer pour publier vos propres extensions à cette spécification (et vous encourageons à les créer !)
### Que dois-je faire si j'utilise accidentellement le type de commit incorrect ?
#### Lorsque vous utilisez un type de commit incorrect, par exemple `fix` au lieu de `feat`
Avant de fusionner ou de publier l'erreur, nous vous recommandons d'utiliser `git rebase -i` pour éditer l'historique du commit.
Après la publication, le nettoyage sera différent selon les outils et les processus que vous utilisez.
#### Lorsque vous utilisez un type qui n'est *pas* dans les spécifications, par exemple `feet` au lieu de` feat`
Dans le pire des cas, ce n'est pas la fin du monde si un commit atterrit sans respecter les spécifications de Commits Conventionnels.
Cela signifie simplement que le commit sera ignoré par des outils basés sur les spécifications.
### Est-ce que tous mes contributeurs doivent utiliser les spécifications de Commits Conventionnels ?
Non ! Si vous utilisez un flux de travail Git basé sur `squash`, les responsables principaux peuvent nettoyer les
messages de validation au fur et à mesure de leur fusion, ce qui permet de ne pas ajouter de charge de travail aux
contributeurs occasionnels.
Un processus courant consiste à ce que votre système Git supprime automatiquement les validations d'une demande
d'extraction et présente un formulaire permettant au responsable de la maintenance d'entrer le message de validation
Git approprié pour la fusion.
### Comment les Commits Conventionnels traitent-ils les annulations de commits ?
L'annulation de code peut être compliquée : est-ce une annulation de plusieurs commits ?
Si vous annulez une fonctionnalité, la prochaine version devrait-elle être un correctif ?
Les Commits Conventionnels ne font pas d'effort explicite pour définir le comportement d'annulation.
Au lieu de cela, nous laissons les auteurs d’outils utiliser la flexibilité des _types_ et des _pieds_
pour développer leur logique de traitement des annulations.
Une recommandation consiste à utiliser le _type_ `revert` et un _pied_ qui fait référence aux SHA de validation qui sont annulés:
```
revert: let us never again speak of the noodle incident
Refs: 676104e, a215868
```
================================================
FILE: content/v1.0.0/index.gr.md
================================================
---
draft: false
aliases: ["/gr/"]
---
# Conventional Commits 1.0.0
## Περίληψη
Η προδιαγραφή Conventional Commits είναι μια ελαφριά σύμβαση για τα μηνύματα commit.
Παρέχει ένα εύκολο σύνολο κανόνων για τη δημιουργία ενός σαφούς ιστορικού των commits,
διευκολύνοντας έτσι τη δημιουργία αυτοματοποιημένων εργαλείων.
Αυτή η σύμβαση συμβαδίζει με το [SemVer](http://semver.org),
περιγράφοντας τα χαρακτηριστικά, τις διορθώσεις και τις αλλαγές που σπάνε τη συμβατότητα (breaking changes) στα μηνύματα των commits.
Το μήνυμα commit πρέπει να έχει την ακόλουθη δομή:
---
```
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
```
---
<br />
Το commit περιέχει τα ακόλουθα δομικά στοιχεία, για να επικοινωνήσει την πρόθεση στους
καταναλωτές της βιβλιοθήκης σας:
1. **fix:** ένα commit τύπου (type) `fix` διορθώνει ένα σφάλμα στον κώδικά σας (αυτό αντιστοιχεί σε `PATCH` στο Semantic Versioning).
1. **feat:** ένα commit τύπου (type) `feat` εισάγει ένα νέο χαρακτηριστικό στον κώδικα (αυτό αντιστοιχεί σε `MINOR` στο Semantic Versioning).
1. **BREAKING CHANGE:** ένα commit που έχει υποσέλιδο (footer) `BREAKING CHANGE:`, ή προσαρτά ένα `!` μετά τον τύπο/scope, εισάγει μια αλλαγή που σπάει τη συμβατότητα του API (breaking change) (αντιστοιχεί σε `MAJOR` στο Semantic Versioning).
Μια αλλαγή που σπάει τη συμβατότητα (BREAKING CHANGE) μπορεί να είναι μέρος οποιουδήποτε τύπου commit.
1. **Τύποι (types)** εκτός από `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:`, και άλλων.
1. **Υποσέλιδα (footers)** εκτός από το `BREAKING CHANGE: <description>` μπορούν να παρέχονται και να ακολουθούν μια σύμβαση παρόμοια με το
[git trailer format](https://git-scm.com/docs/git-interpret-trailers).
Η χρήση πρόσθετων τύπων δεν επιβάλλεται από την προδιαγραφή Conventional Commits και δεν επηρεάζει το Semantic Versioning (εκτός αν περιλαμβάνουν μια αλλαγή που σπάει τη συμβατότητα - BREAKING CHANGE).
<br /><br />
Ένα scope (πεδίο εφαρμογής) μπορεί να δοθεί στον τύπο ενός commit για να παρέχει πρόσθετες πληροφορίες πλαισίου και περικλείεται σε παρενθέσεις, π.χ., `feat(parser): add ability to parse arrays`.
## Παραδείγματα
### Μήνυμα commit με περιγραφή και υποσέλιδο για breaking change
```
feat: allow provided config object to extend other configs
BREAKING CHANGE: `extends` key in config file is now used for extending other config files
```
### Μήνυμα commit με `!` για την επισήμανση μιας breaking change
```
feat!: send an email to the customer when a product is shipped
```
### Μήνυμα commit με scope και `!` για την επισήμανση μιας breaking change
```
feat(api)!: send an email to the customer when a product is shipped
```
### Μήνυμα commit με `!` και υποσέλιδο BREAKING CHANGE
```
chore!: drop support for Node 6
BREAKING CHANGE: use JavaScript features not available in Node 6.
```
### Μήνυμα commit χωρίς σώμα
```
docs: correct spelling of CHANGELOG
```
### Μήνυμα commit με scope
```
feat(lang): add Polish language
```
### Μήνυμα commit με σώμα πολλαπλών παραγράφων και πολλαπλά υποσέλιδα
```
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. Τα Commits ΠΡΕΠΕΙ να ξεκινούν με ένα πρόθεμα τύπου, το οποίο αποτελείται από ένα ουσιαστικό, `feat`, `fix`, κ.λπ., ακολουθούμενο
από το ΠΡΟΑΙΡΕΤΙΚΟ scope (πεδίο εφαρμογής), το ΠΡΟΑΙΡΕΤΙΚΟ `!`, και την ΑΠΑΙΤΟΥΜΕΝΗ άνω και κάτω τελεία και κενό διάστημα.
1. Ο τύπος `feat` ΠΡΕΠΕΙ να χρησιμοποιείται όταν ένα commit προσθέτει ένα νέο χαρακτηριστικό στην εφαρμογή ή τη βιβλιοθήκη σας.
1. Ο τύπος `fix` ΠΡΕΠΕΙ να χρησιμοποιείται όταν ένα commit αντιπροσωπεύει μια διόρθωση σφάλματος για την εφαρμογή σας.
1. Ένα scope ΜΠΟΡΕΙ να δοθεί μετά από έναν τύπο. Ένα scope ΠΡΕΠΕΙ να αποτελείται από ένα ουσιαστικό που περιγράφει ένα
τμήμα του κώδικα, περικλειόμενο σε παρενθέσεις, π.χ., `fix(parser):`
1. Μια περιγραφή ΠΡΕΠΕΙ να ακολουθεί αμέσως την άνω και κάτω τελεία και το κενό μετά το πρόθεμα τύπου/scope.
Η περιγραφή είναι μια σύντομη περίληψη των αλλαγών του κώδικα, π.χ., _fix: array parsing issue when multiple spaces were contained in string_.
1. Ένα μεγαλύτερο σώμα commit ΜΠΟΡΕΙ να δοθεί μετά τη σύντομη περιγραφή, παρέχοντας πρόσθετες πληροφορίες πλαισίου σχετικά με τις αλλαγές του κώδικα. Το σώμα ΠΡΕΠΕΙ να ξεκινά μία κενή γραμμή μετά την περιγραφή.
1. Ένα σώμα commit είναι ελεύθερης μορφής και ΜΠΟΡΕΙ να αποτελείται από οποιονδήποτε αριθμό παραγράφων που χωρίζονται με νέα γραμμή.
1. Ένα ή περισσότερα υποσέλιδα ΜΠΟΡΕΙ να δοθούν μία κενή γραμμή μετά το σώμα. Κάθε υποσέλιδο ΠΡΕΠΕΙ να αποτελείται από
ένα token λέξης-κλειδιού, ακολουθούμενο είτε από ένα διαχωριστικό `:<space>` είτε `<space>#`, ακολουθούμενο από μια τιμή τύπου string (αυτό είναι εμπνευσμένο από τη
[σύμβαση git trailer](https://git-scm.com/docs/git-interpret-trailers)).
1. Το token λέξης-κλειδιού ενός υποσέλιδου ΠΡΕΠΕΙ να χρησιμοποιεί `-` αντί για κενά διαστήματα, π.χ., `Acked-by` (αυτό βοηθά στη διαφοροποίηση
του τμήματος του υποσέλιδου από ένα σώμα πολλαπλών παραγράφων). Εξαίρεση γίνεται για το `BREAKING CHANGE`, το οποίο ΜΠΟΡΕΙ επίσης να χρησιμοποιηθεί ως token λέξης-κλειδιού.
1. Η τιμή ενός υποσέλιδου ΜΠΟΡΕΙ να περιέχει κενά και νέες γραμμές, και η διαδικασία parsing ΠΡΕΠΕΙ να τερματίζεται όταν εντοπιστεί το επόμενο έγκυρο ζεύγος
token λέξης-κλειδιού/διαχωριστικού.
1. Οι αλλαγές που σπάνε τη συμβατότητα (breaking changes) ΠΡΕΠΕΙ να υποδεικνύονται στο πρόθεμα τύπου/scope ενός commit, ή ως εγγραφή στο
υποσέλιδο.
1. Εάν περιλαμβάνεται ως υποσέλιδο, μια αλλαγή που σπάει τη συμβατότητα ΠΡΕΠΕΙ να αποτελείται από το κεφαλαίο κείμενο BREAKING CHANGE, ακολουθούμενο από άνω και κάτω τελεία, κενό και περιγραφή, π.χ.,
_BREAKING CHANGE: οι μεταβλητές περιβάλλοντος έχουν πλέον προτεραιότητα έναντι των αρχείων διαμόρφωσης_.
1. Εάν περιλαμβάνεται στο πρόθεμα τύπου/scope, οι αλλαγές που σπάνε τη συμβατότητα ΠΡΕΠΕΙ να υποδεικνύονται με ένα
`!` αμέσως πριν από το `:`. Εάν χρησιμοποιείται το `!`, το `BREAKING CHANGE:` ΜΠΟΡΕΙ να παραλειφθεί από το τμήμα του υποσέλιδου,
και η περιγραφή του commit ΠΡΕΠΕΙ να χρησιμοποιείται για την περιγραφή της αλλαγής που σπάει τη συμβατότητα.
1. Τύποι εκτός από `feat` και `fix` ΜΠΟΡΕΙ να χρησιμοποιηθούν στα μηνύματα commit σας, π.χ., _docs: update ref docs._
1. Για τα στοιχεία που συνθέτουν τα Conventional Commits ΔΕΝ ΠΡΕΠΕΙ να γίνεται διάκριση πεζών-κεφαλαίων από τους υλοποιητές, με εξαίρεση το `BREAKING CHANGE` που ΠΡΕΠΕΙ να είναι με κεφαλαία γράμματα.
1. Το `BREAKING-CHANGE` ΠΡΕΠΕΙ να είναι συνώνυμο με το `BREAKING CHANGE`, όταν χρησιμοποιείται ως token λέξης-κλειδιού σε ένα υποσέλιδο.
## Γιατί να χρησιμοποιήσετε τα Conventional Commits
* Αυτόματη δημιουργία CHANGELOGs.
* Αυτόματος προσδιορισμός μιας αύξησης της σημασιολογικής έκδοσης (με βάση τους τύπους των commits που έχουν ενσωματωθεί).
* Επικοινωνία της φύσης των αλλαγών στους συμπαίκτες, το κοινό και άλλους ενδιαφερόμενους.
* Ενεργοποίηση διαδικασιών build και publish.
* Διευκόλυνση της συνεισφοράς άλλων στα έργα σας, επιτρέποντάς τους να εξερευνήσουν
ένα πιο δομημένο ιστορικό των commits.
## Συχνές Ερωτήσεις
### Πώς πρέπει να χειρίζομαι τα μηνύματα commit στην αρχική φάση ανάπτυξης;
Σας συνιστούμε να προχωρήσετε σαν να έχετε ήδη κυκλοφορήσει το προϊόν. Συνήθως *κάποιος*, ακόμα κι αν είναι οι συνάδελφοί σας προγραμματιστές, χρησιμοποιεί το λογισμικό σας. Θα θέλουν να ξέρουν τι έχει διορθωθεί, ποιες αλλαγές σπάνε τη συμβατότητα, κ.λπ.
### Οι τύποι στον τίτλο του commit είναι κεφαλαίοι ή πεζοί;
Μπορεί να χρησιμοποιηθεί οποιαδήποτε μορφή (πεζά ή κεφαλαία), αλλά είναι καλύτερο να είστε συνεπείς.
### Τι κάνω αν το commit συμμορφώνεται με περισσότερους από έναν από τους τύπους commit;
Προσπαθήστε να δημιουργήσετε πολλαπλά commits όποτε είναι δυνατόν. Μέρος του οφέλους των Conventional Commits είναι η ικανότητά του να μας οδηγεί στο να κάνουμε πιο οργανωμένα commits και PRs.
### Αυτό δεν αποθαρρύνει την ταχεία ανάπτυξη και τη γρήγορη επανάληψη;
Αποθαρρύνει το να κινείστε γρήγορα με ανοργάνωτο τρόπο. Σας βοηθά να μπορείτε να κινείστε γρήγορα μακροπρόθεσμα σε πολλαπλά έργα με ποικίλους συνεισφέροντες.
### Μπορεί τα Conventional Commits να οδηγήσουν τους προγραμματιστές να περιορίσουν τον τύπο των commits που κάνουν επειδή θα σκέφτονται με τους παρεχόμενους τύπους;
Τα Conventional Commits μας ενθαρρύνουν να κάνουμε περισσότερους από ορισμένους τύπους commits, όπως διορθώσεις. Πέρα από αυτό, η ευελιξία των Conventional Commits επιτρέπει στην ομάδα σας να δημιουργήσει τους δικούς της τύπους και να τους αλλάξει με την πάροδο του χρόνου.
### Πώς σχετίζεται αυτό με το SemVer;
Τα commits τύπου `fix` πρέπει να μεταφράζονται σε `PATCH` εκδόσεις. Τα commits τύπου `feat` πρέπει να μεταφράζονται σε `MINOR` εκδόσεις. Τα commits με `BREAKING CHANGE` στα commits, ανεξάρτητα από τον τύπο, πρέπει να μεταφράζονται σε `MAJOR` εκδόσεις.
### Πώς πρέπει να εκδίδω τις επεκτάσεις μου στην Προδιαγραφή Conventional Commits, π.χ. `@jameswomack/conventional-commit-spec`;
Συνιστούμε τη χρήση του SemVer για την κυκλοφορία των δικών σας επεκτάσεων σε αυτήν την προδιαγραφή (και
σας ενθαρρύνουμε να κάνετε αυτές τις επεκτάσεις!)
### Τι κάνω αν κατά λάθος χρησιμοποιήσω λάθος τύπο commit;
#### Όταν χρησιμοποιήσατε έναν τύπο που είναι της προδιαγραφής αλλά όχι ο σωστός τύπος, π.χ. `fix` αντί για `feat`
Πριν από τη συγχώνευση ή την κυκλοφορία του λάθους, συνιστούμε τη χρήση του `git rebase -i` για την επεξεργασία του ιστορικού των commits. Μετά την κυκλοφορία, η διόρθωση θα είναι διαφορετική ανάλογα με τα εργαλεία και τις διαδικασίες που χρησιμοποιείτε.
#### Όταν χρησιμοποιήσατε έναν τύπο *όχι* της προδιαγραφής, π.χ. `feet` αντί για `feat`
Στο χειρότερο σενάριο, δεν είναι το τέλος του κόσμου αν ένα commit που δεν πληροί την προδιαγραφή Conventional Commits ενσωματωθεί. Σημαίνει απλώς ότι το commit θα παραλειφθεί από εργαλεία που βασίζονται στην προδιαγραφή.
### Πρέπει όλοι οι συνεισφέροντες μου να χρησιμοποιούν την προδιαγραφή Conventional Commits;
Όχι! Εάν χρησιμοποιείτε μια ροή εργασίας βασισμένη στο squash στο Git, οι κύριοι συντηρητές μπορούν να επεξεργαστούν τα μηνύματα των commits καθώς τα συγχωνεύουν—χωρίς να προσθέτουν φόρτο εργασίας στους περιστασιακούς συνεισφέροντες.
Μια κοινή ροή εργασίας για αυτό είναι το σύστημά σας git να κάνει αυτόματα squash τα commits από ένα pull request και να παρουσιάζει μια φόρμα στον κύριο συντηρητή για να εισαγάγει το σωστό μήνυμα git commit για τη συγχώνευση.
### Πώς χειρίζονται τα Conventional Commits τα revert commits;
Η αναίρεση κώδικα μπορεί να είναι περίπλοκη: αναιρείτε πολλαπλά commits; αν αναιρέσετε ένα χαρακτηριστικό, θα πρέπει η επόμενη έκδοση να είναι patch;
Τα Conventional Commits δεν προσπαθούν ρητά να ορίσουν τη συμπεριφορά αναίρεσης. Αντ' αυτού, το αφήνουμε στους δημιουργούς εργαλείων
να χρησιμοποιήσουν την ευελιξία των τύπων (types) και των υποσέλιδων (footers) για να αναπτύξουν τη λογική τους για το χειρισμό των αναιρέσεων.
Μια σύσταση είναι να χρησιμοποιήσετε τον τύπο `revert` και ένα υποσέλιδο που αναφέρεται στα SHA των commits που αναιρούνται:
```
revert: let us never again speak of the noodle incident
Refs: 676104e, a215868
```
================================================
FILE: content/v1.0.0/index.hi.md
================================================
---
draft: false
aliases: ["/hi/"]
---
# कन्वेंशनल कमिट्स 1.0.0
## Summary
## सारांश
कन्वेंशनल कमिट्स विनिर्देश कमिट संदेशों पर एक हल्का सम्मेलन है।
यह एक स्पष्ट कमिट इतिहास बनाने के लिए नियमों का एक आसान सेट प्रदान करता है;
जिससे स्वचालित उपकरण लिखना आसान हो जाता है।
यह सम्मेलन [SemVer](http://semver.org),
कमिट संदेशों में किए गए फीचर्स, फिक्सेस और ब्रेकिंग चेंजेस का वर्णन करके के साथ जुड़ता है।
कमिट संदेश को निम्नानुसार संरचित किया जाना चाहिए:
---
```
<type>[वैकल्पिक स्कोप]: <विवरण>
[वैकल्पिक बॉडी]
[वैकल्पिक फुटर(स)]
```
---
<br />
कमिट में निम्नलिखित संरचनात्मक तत्व होते हैं, आपके पुस्तकालय के उपभोक्ताओं को इरादा बताने के लिए:
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:` के अलावा अन्य _टाइप्स_ की अनुमति है, उदाहरण के लिए [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) ( [Angular convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines) पर आधारित) `build:`, `chore:`,
`ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, और अन्य की सिफारिश करता है।
1. `BREAKING CHANGE: <विवरण>` के अलावा अन्य _फुटर_ प्रदान किए जा सकते हैं और [git trailer format](https://git-scm.com/docs/git-interpret-trailers) के समान सम्मेलन का पालन करते हैं।
अतिरिक्त टाइप्स कन्वेंशनल कमिट्स विनिर्देश द्वारा अनिवार्य नहीं हैं, और सेमैंटिक वर्जनिंग में कोई अंतर्निहित प्रभाव नहीं है (जब तक वे BREAKING CHANGE शामिल नहीं करते)।
<br /><br />
एक स्कोप कमिट के टाइप को प्रदान किया जा सकता है, अतिरिक्त संदर्भ जानकारी प्रदान करने के लिए और कोष्ठक में समाहित है, जैसे `feat(parser): arrays parse करने की क्षमता जोड़ें`।
## उदाहरण
### विवरण और ब्रेकिंग चेंज फुटर के साथ कमिट संदेश
```
feat: provided config object को अन्य configs को extend करने की अनुमति दें
BREAKING CHANGE: config file में `extends` key अब अन्य config files को extend करने के लिए इस्तेमाल किया जाता है
```
### ब्रेकिंग चेंज पर ध्यान आकर्षित करने के लिए `!` के साथ कमिट संदेश
```
feat!: जब कोई प्रोडक्ट शिप हो जाए तो कस्टमर को email भेजें
```
### स्कोप और `!` के साथ कमिट संदेश ब्रेकिंग चेंज पर ध्यान आकर्षित करने के लिए
```
feat(api)!: जब कोई प्रोडक्ट शिप हो जाए तो कस्टमर को email भेजें
```
### `!` और BREAKING CHANGE फुटर दोनों के साथ कमिट संदेश
```
chore!: Node 6 के लिए सपोर्ट छोड़ दें
BREAKING CHANGE: Node 6 में उपलब्ध नहीं होने वाले JavaScript features का इस्तेमाल करें।
```
### बॉडी के बिना कमिट संदेश
```
docs: CHANGELOG की spelling सही करें
```
### स्कोप के साथ कमिट संदेश
```
feat(lang): Polish language जोड़ें
```
### मल्टी-पैराग्राफ बॉडी और मल्टीपल फुटर के साथ कमिट संदेश
```
fix: requests के racing को रोकें
एक request id और latest request का reference पेश करें। latest request से अलावा आने वाले responses को खारिज करें।
timeouts को हटा दें जो racing issue को कम करने के लिए इस्तेमाल किए जाते थे लेकिन अब obsolete हैं।
Reviewed-by: Z
Refs: #123
```
## Specification
## पूरी विशिष्टता
इस दस्तावेज़ में “जरूरी”("MUST"), “आवश्यक नहीं”("MUST NOT"), “आवश्यक”("REQUIRED"), “साझा करें”("SHALL"), “नहीं होगा”("SHALL NOT"), “चाहिए”("SHOULD"), “नहीं होना चाहिए”("SHOULD NOT"), “अनुशंसित”("RECOMMENDED"), “मई”(MAY"), और “वैकल्पिक”("OPTIONAL") कीवर्ड को [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) में वर्णित अनुसार व्याख्या किया जाना चाहिए।
1. कमिट्स को एक टाइप से शुरू होना चाहिए, जिसमें एक noun, `feat`, `fix`, आदि शामिल है, इसके बाद OPTIONAL स्कोप, OPTIONAL `!`, और REQUIRED terminal colon और space।
2. टाइप `feat` का इस्तेमाल तब किया जाना चाहिए जब एक कमिट आपके एप्लिकेशन या लाइब्रेरी में एक नई फीचर जोड़ता है।
3. टाइप `fix` का इस्तेमाल तब किया जाना चाहिए जब एक कमिट आपके एप्लिकेशन के लिए एक बग फिक्स का प्रतिनिधित्व करता है।
4. एक स्कोप टाइप के बाद प्रदान किया जा सकता है। एक स्कोप को कोडबेस के एक सेक्शन का वर्णन करने वाले noun से मिलकर होना चाहिए, कोष्ठक में घिरा हुआ, जैसे `fix(parser):`
5. एक विवरण टाइप/स्कोप prefix के बाद colon और space के तुरंत बाद आना चाहिए।
विवरण कोड चेंजेस का एक छोटा सारांश है, जैसे _fix: array parsing issue जब string में multiple spaces थे_।
1. एक लंबा कमिट बॉडी विवरण के बाद प्रदान किया जा सकता है, कोड चेंजेस के बारे में अतिरिक्त संदर्भ जानकारी प्रदान करके। बॉडी को विवरण के बाद एक blank line से शुरू होना चाहिए।
2. एक कमिट बॉडी free-form है और किसी भी संख्या में newline separated paragraphs से मिलकर हो सकता है।
3. एक या अधिक फुटर बॉडी के बाद एक blank line के बाद प्रदान किए जा सकते हैं। प्रत्येक फुटर को एक word token से मिलकर होना चाहिए, इसके बाद या तो `:<space>` या `<space>#` separator, इसके बाद एक string value (यह [git trailer convention](https://git-scm.com/docs/git-interpret-trailers) से प्रेरित है)।
4. एक फुटर के token में whitespace characters की जगह `-` का इस्तेमाल करना चाहिए, जैसे `Acked-by` (यह फुटर सेक्शन को multi-paragraph बॉडी से अलग करने में मदद करता है)। `BREAKING CHANGE` के लिए एक अपवाद बनाया गया है, जो token के रूप में भी इस्तेमाल किया जा सकता है।
5. एक फुटर की value में spaces और newlines हो सकते हैं, और parsing तब समाप्त होना चाहिए जब अगला valid footer token/separator pair observed हो।
6. ब्रेकिंग चेंजेस को कमिट के टाइप/स्कोप prefix में या फुटर में entry के रूप में इंगित किया जाना चाहिए।
7. यदि फुटर के रूप में शामिल किया गया है, तो एक ब्रेकिंग चेंज uppercase text BREAKING CHANGE से मिलकर होना चाहिए, इसके बाद colon, space, और विवरण, जैसे _BREAKING CHANGE: environment variables अब config files पर precedence लेते हैं_।
8. यदि टाइप/स्कोप prefix में शामिल किया गया है, तो ब्रेकिंग चेंजेस को `!` से इंगित किया जाना चाहिए `:` से पहले। यदि `!` इस्तेमाल किया गया है, तो `BREAKING CHANGE:` फुटर सेक्शन से omitted किया जा सकता है, और कमिट विवरण ब्रेकिंग चेंज का वर्णन करने के लिए इस्तेमाल किया जाएगा।
9. `feat` और `fix` के अलावा अन्य टाइप्स आपके कमिट संदेशों में इस्तेमाल किए जा सकते हैं, जैसे _docs: update ref docs._।
10. कन्वेंशनल कमिट्स बनाने वाली information units को implementors द्वारा case sensitive नहीं माना जाना चाहिए, BREAKING CHANGE के अपवाद के साथ जो uppercase होना चाहिए।
11. BREAKING-CHANGE को BREAKING CHANGE के समानार्थी होना चाहिए, जब फुटर में token के रूप में इस्तेमाल किया जाए।
## कन्वेंशनल कमिट्स क्यों इस्तेमाल करें
* स्वचालित रूप से CHANGELOGs जनरेट करना।
* स्वचालित रूप से सेमैंटिक वर्जन bump निर्धारित करना (landed कमिट्स के टाइप्स पर आधारित)।
* चेंजेस की nature को teammates, the public, और अन्य stakeholders को बताना।
* बिल्ड और publish प्रोसेस ट्रिगर करना।
* लोगों को आपके प्रोजेक्ट्स में contribute करना आसान बनाना, उन्हें एक अधिक structured कमिट इतिहास explore करने की अनुमति देकर।
## FAQ
## सामान्य प्रश्न
### प्रारंभिक development phase में कमिट संदेशों से कैसे निपटें?
हम सिफारिश करते हैं कि आप ऐसा behave करें जैसे आपने पहले ही प्रोडक्ट रिलीज़ कर दिया हो। आमतौर पर *कोई*, भले ही यह आपके fellow software developers हों, आपके software का इस्तेमाल कर रहा है। वे जानना चाहेंगे कि क्या fixed है, क्या breaks है आदि।
### कमिट title में टाइप्स uppercase या lowercase हैं?
कोई भी casing इस्तेमाल की जा सकती है, लेकिन consistent रहना सबसे अच्छा है।
### क्या करें यदि कमिट एक से अधिक कमिट टाइप्स के अनुरूप है?
जब भी संभव हो, वापस जाकर multiple कमिट्स बनाएं। कन्वेंशनल कमिट्स के लाभों में से एक यह है कि यह हमें अधिक organized कमिट्स और PRs बनाने के लिए drive करता है।
### क्या यह rapid development और fast iteration को discourage नहीं करता?
यह disorganized तरीके से fast move करने को discourage करता है। यह आपको long term में multiple प्रोजेक्ट्स में fast move करने में मदद करता है varied contributors के साथ।
### क्या कन्वेंशनल कमिट्स developers को उनके द्वारा किए जाने वाले कमिट्स के टाइप को limit करने के लिए lead कर सकता है क्योंकि वे provided टाइप्स में सोच रहे होंगे?
कन्वेंशनल कमिट्स हमें fixes जैसे कुछ टाइप्स के अधिक कमिट्स बनाने के लिए encourage करता है। इसके अलावा, कन्वेंशनल कमिट्स की flexibility आपकी team को अपने own टाइप्स develop करने और समय के साथ उन टाइप्स को change करने की अनुमति देती है।
### यह SemVer से कैसे संबंधित है?
`fix` टाइप कमिट्स को `PATCH` रिलीज़ में translate किया जाना चाहिए। `feat` टाइप कमिट्स को `MINOR` रिलीज़ में translate किया जाना चाहिए। कमिट्स में `BREAKING CHANGE` के साथ, टाइप की परवाह किए बिना, को `MAJOR` रिलीज़ में translate किया जाना चाहिए।
### कन्वेंशनल कमिट्स विनिर्देश के अपने extensions को कैसे version करें, जैसे `@jameswomack/conventional-commit-spec`?
हम सिफारिश करते हैं कि इस विनिर्देश के अपने extensions को रिलीज़ करने के लिए SemVer का इस्तेमाल करें (और हम आपको ये extensions बनाने के लिए encourage करते हैं!)
### क्या करें यदि मैंने accidentally गलत कमिट टाइप इस्तेमाल किया?
#### जब आपने spec का टाइप इस्तेमाल किया लेकिन सही टाइप नहीं, जैसे `fix` instead of `feat`
मर्ज या रिलीज़ से पहले, हम `git rebase -i` का इस्तेमाल करके कमिट इतिहास edit करने की सिफारिश करते हैं। रिलीज़ के बाद, cleanup आपके द्वारा इस्तेमाल किए जाने वाले tools और processes के अनुसार अलग होगा。
#### जब आपने spec का टाइप *नहीं* इस्तेमाल किया, जैसे `feet` instead of `feat`
worst case scenario में, यह दुनिया का अंत नहीं है यदि एक कमिट land करता है जो कन्वेंशनल कमिट्स विनिर्देश को पूरा नहीं करता। इसका मतलब सिर्फ इतना है कि वह कमिट spec पर आधारित tools द्वारा missed हो जाएगा।
### क्या मेरे सभी contributors को कन्वेंशनल कमिट्स विनिर्देश इस्तेमाल करना जरूरी है?
नहीं! यदि आप Git पर squash based workflow इस्तेमाल करते हैं तो lead maintainers कमिट संदेशों को clean up कर सकते हैं जैसे वे merged होते हैं—casual committers पर कोई workload नहीं जोड़ते।
इसके लिए एक common workflow यह है कि आपका git system स्वचालित रूप से pull request से कमिट्स को squash करता है और lead maintainer को merge के लिए proper git कमिट संदेश enter करने के लिए एक form प्रस्तुत करता है।
### कन्वेंशनल कमिट्स revert कमिट्स को कैसे handle करता है?
कोड revert करना complicated हो सकता है: क्या आप multiple कमिट्स revert कर रहे हैं? यदि आप एक फीचर revert करते हैं, तो क्या अगली रिलीज़ instead एक patch होनी चाहिए?
कन्वेंशनल कमिट्स revert behavior को define करने के लिए explicit effort नहीं करता। इसके बजाय हम इसे tooling authors पर छोड़ते हैं कि वे reverts को handle करने के लिए _टाइप्स_ और _फुटर_ की flexibility का इस्तेमाल करें।
एक recommendation `revert` टाइप इस्तेमाल करना है, और एक फुटर जो revert किए जा रहे कमिट SHAs का reference देता है:
```
revert: आइए हम कभी भी noodle incident की बात न करें
Refs: 676104e, a215868
```
================================================
FILE: content/v1.0.0/index.hy.md
================================================
---
draft: false
aliases: ["/hy/"]
---
# Conventional Commits 1.0.0
## Ամփոփում
Conventional Commits-ը իրենից ներկայացնում է թեթև կոնվենցիաներ՝ commit հաղորդագրությունների վրա։
Այն ապահովում է պարզ commit-ների պատմություն ստեղծելու հեշտ եղանակ, ինչը հեշտացնում է ավտոմատացման գործիքների օգտագործումը։
Այս կոնվենցիան համընկնում է [SemVer](http://semver.org)-ի հետ,
նկարագրելով commit հաղորդագրություններում կատարված առանձնահատկությունները, ուղղումները և փոփոխությունները:
Commit հաղորդագրությունները պետք է ունենան հետևյալ կառուցվածքը․
---
```
<տիպ>[ոչ պարտադիր շրջանակ]: <նկարագրություն>
[ոչ պարտադիր մարմին]
[ոչ պարտադիր վերջավորություն(ներ)]
```
---
<br />
Commit-ը պարունակում է հետևյալ կառուցվածքային տարրերը՝ ձեր փոփոխությունների մտադրությունը հաղորդելու համար.
1. **fix:** այն commit-ները, որոնք պատկանում են `fix` _տիպին_ , իրենցից ներկայացնում են բագերի ուղղումներ (այն համապատասխանում է Semantic Versioning-ի [`PATCH`](http://semver.org/#summary) տեսակին)։
1. **feat:** այն commit-ները, որոնք պատկանում են `feat` _տիպին_ , իրենցից ներկայացնում են նոր հատկանիշների ավելացում (այն համապատասխանում է Semantic Versioning-ի [`MINOR`](http://semver.org/#summary) տեսակին)։
1. **BREAKING CHANGE:** այն commit-ները, որոնք ունեն `BREAKING CHANGE:` վերջավորությունը, կամ ընդգրկում են `!` նշանը, տիպից(շրջանակից) հետո, իրենցից ներկայացնում են կարևոր կամ բեկումնային փոփոխություններ (այն համապատասխանում է Semantic Versioning-ի [`MAJOR`](http://semver.org/#summary) տեսակին)։
BREAKING CHANGE-ը կարող է հանդիսանալ ցանկացած տիպի commit-ի մաս։
1. `fix:`-ից և `feat:`-ից բացի այլ տիպերի օգտագործումը թույլատրվում է, օրինակ՝ [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config) (հիմնվելով [Angular-ի կոնվենցիայի](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines) վրա) առաջարկում է `build:`, `chore:`,
`ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:` և այլն:
1. `BREAKING CHANGE: <description>` բացի այլ վերջավորություններ կարող են տրամադրվել և հետևել [git թրեյլերի ձևաչափ](https://git-scm.com/docs/git-interpret-trailers)-ին հարակից կոնվենցիաներին։
Լրացուցիչ տիպերը պարտադիր չեն Conventional Commits-ի դասակարգմամբ և չունեն անուղղակի ազդեցություն իմաստային տարբերակման մեջ (եթե դրանք չեն ներառում BREAKING CHANGE):
<br /><br />
Հանձնարարականի տիպին կարող է տրվել շրջանակ՝ լրացուցիչ համատեքստային ինֆորմացիա տրամադրելու համար։ Այն օգտագործվում է փակագծերի մեջ, հետևյալ կերպ՝ `feat(parser): add ability to parse arrays`:
## Օրինակներ
### Commit հաղորդագրություն՝ նկարագրով և breaking change վերջավորությունով
```
feat: allow provided config object to extend other configs
BREAKING CHANGE: `extends` key in config file is now used for extending other config files
```
### Commit հաղորդագրություն՝ `!` նշանով, որպեսզի ուշադրություն գրավենք կատարված կարևոր փոփոխությունների համար
```
feat!: send an email to the customer when a product is shipped
```
### Commit հաղորդագրություն՝ շրջանակով և `!` նշանով, որպեսզի ուշադրություն գրավենք կատարված կարևոր փոփոխությունների համար
```
feat(api)!: send an email to the customer when a product is shipped
```
### Commit հաղորդագրություն՝ միաժամանակ և՛ `!` նշանով, և՛ BREAKING CHANGE վերջավորությունով
```
feat!: drop support for Node 6
BREAKING CHANGE: use JavaScript features not available in Node 6.
```
### Commit հաղորդագրություն՝ առանց մարմնի
```
docs: correct spelling of CHANGELOG
```
### Commit հաղորդագրություն՝ շրջանակով
```
feat(lang): add Polish language
```
### Commit հաղորդագրություն՝ մի քանի պարագրաֆ մարմնով և մի քանի վերջավորություններով
```
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”, and “OPTIONAL” բառերն այս փաստաթղթում պետք է մեկնաբանվեն այնպես, ինչպես նկարագրված է [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt)-ում։
1. Commit-ները պետք է ունեն տիպ՝ նախածանցի տեսքով, որը պետք է բաղկացած լինի գոյականից, `feat`, `fix` և այլն, որին հաջորդում են ոչ պարտադիր շրջանակը, ոչ պարտադիր `!`-ը և պարտադիր վերջակետ ու բացատ:
1. `feat` տիպը պետք է օգտագործել այն ժամանակ, երբ Ձեր ծրագրում ավելացնում եք նոր հատկանիշներ։
1. `fix` տիպը պետք է օգտագործել այն ժամանակ, երբ Ձեր ծրագրում կատարում եք ուղղումներ։
1. Շրջանակը պետք է նշել տիպից հետո՝ փակագծերի մեջ։ Այն կարող է լինել Ձեր փոփոխած հատվածի վերնագիրը, օրինակ` `fix(parser):`։
1. Նկարագիրը պետք է գրված լինի տիպից կամ շրջանակից հետո՝ պահելով դրանց միջև վերջակետ և բացատ։
Այն Ձեր կատարած փոփոխությունների կարճ նկարագիրն է, օրինակ՝ _fix: array parsing issue when multiple spaces were contained in string_։
1. Մարմինը կարելի է գրել նկարագրությունից հետո։ Այն Ձեր կատարած փոփոխությունների լայն նկարագիրն է։ Այն պետք է պահի մեկ դատարկ տող՝ նկարագրի միջև։
1. Commit-ի մարմինը ունի ազատ գրելաձև, կարող է պարունակել տառեր, թվեր, մի քանի պարբերություններ և այլն։
1. Մեկ կամ ավելի վերջավորությունները պետք է ունենան մեկ դատարկ տող՝ առանձնացվելով մարմնից(ավելին կարող եք կարդալ
[git trailer convention](https://git-scm.com/docs/git-interpret-trailers)-ում)։
1. Վերջավորության նշանը պետք Է օգտագործի `-`՝ բացատ նիշերի փոխարեն, օրինակ՝ `Acked-by` (սա օգնում է տարբերակել վերջավորությունը բազմաբնույթ պարբերությունից): Բացառություն է արվում `BREAKING CHANGE-ի համար, որը կարող Է օգտագործվել նաև որպես նշան:
1. Վերջավորության արժեքը կարող Է պարունակել բացատներ և նոր տողեր, և վերլուծությունը պետք Է ավարտվի, երբ հաջորդ վավեր վերջավորությունը
նկատվում է:
1. Breaking change-երը պետք է նշված լինեն տիպում կամ շրջանակում, և կամ էլ վերջավորության մեջ։
1. Եթե գոյություն ունի վերջավորություն, ապա breaking change-ը պետք է լինի մեծատառ, օրինակ՝
_BREAKING CHANGE: environment variables now take precedence over config files_։
1. Եթե ներառված է տիպի(շրջանակի) նախածանցում, ապա խախտման փոփոխությունները պետք Է նշված լինեն
`!` `:`-ից անմիջապես առաջ: Եթե `!`-ն օգտագործվում է, `BREAKING CHANGE`-ը կարող է բաց թողնել ստորագիր հատվածից,
և պարտավորության նկարագրությունը պետք Է օգտագործվի՝ նկարագրելու փոփոխությունը:
1. `feat` և `fix` տիպերից բացի կարող են օգտագործվել Ձեր commit հաղորդագրություններում, օրինակ՝ _docs: updated ref docs._։
1. Այն ինֆորմացիոն տարրերը, որոնք կազմված են Conventional Commits-ի MUST NOT տեսակից իրականացնողների կողմից դիտարկվում են, որպես գործի զգայուն հատված, բացառությամբ BREAKING CHANGE-ի որը պետք է լինի մեծատառ։
1. BREAKING-CHANGE MUST-ը BREAKING CHANGE հոմանիշն է, երբ օգտագործվում է, որպես վերջավորություն։
## Ինչ՞ու օգտագործել Conventional Commits-ը
* Ավտոմատ կերպով գեներացնում են CHANGELOG-ներ։
* Ավտոմատ կերպով կատարում են տարբերակների բարձրացում (հիմնվելով կատարված commit-ների տեսակի վրա)։
* Փոփոխությունների բնույթի հաղորդում թիմակիցներին, հանրությանը և այլ շահագրգիռ կողմերին:
* Ստեղծման և հրապարակման գործընթացների ակտիվացում:
* Առավել հեշտացնում է նպաստումը Ձեր նախագծին այլ մարդկանց կողմից՝ թույլ տալով նրանց ուսումնասիրել ավելի ընթեռնելի commit-ների պատմություն:
## Հ․Տ․Հ․
### Ինչպե՞ս պետք է վարվեմ commit հաղորդագրությունների հետ նախնական զարգացման փուլում:
Մենք խորհուրդ ենք տալիս շարունակել այնպես, կարծես արդեն թողարկել եք պրոդուկտը: Սովորաբար *ինչ-որ մեկը*, նույնիսկ եթե դա ձեր գործընկեր ծրագրավորողներն են, օգտագործում է ձեր ծրագրաշարը: Նրանք կցանկանան իմանալ, թե ինչն է շտկված, ինչն է կոտրվում և այլն:
### Commit-ների վերնագրի տեսակները մեծատառե՞ն են, թե՞ փոքրատառ:
Ցանկացած միջոց կարող է օգտագործվել, բայց ավելի լավ է հետևողական լինել և օգտագործել դրանցից որևէ մեկը:
### Ի՞նչ անել, եթե commit-ը համապատասխանում է commit-ների մեկից ավելի տեսակներին:
Վերադարձեք և հնարավորության դեպքում մի քանի commit-ներ կատարեք: Conventional Commits-ը օգտագործելու իմաստներից մեկը՝ մեր commit հաղորդագրություններն ու PR-ները ավելի կազմակերպված դարձնելն է:
### Արդյո՞ք սա չի խանգարում պրոյեկտի արագ զարգացմանը և արագ կրկնմանը:
Այն խանգարում է արագ շարժվել անկազմակերպ կերպով: Այն օգնում է Ձեզ երկարաժամկետ արագ շարժվել բազմաթիվ նախագծերի մեջ՝ տարբեր ներդրողների հետ:
### Հնարավո՞ր է, որ Conventional Commits-ը ծրագրավորողներին սահմանափակի իրենց կատարած commit-ների տեսակը, քանի որ նրանք կմտածեն տրամադրված տեսակների վրա:
Conventional Commits-ը մեզ խրախուսում է ավելի շատ կատարել որոշակի տեսակի commit-ներ, ինչպիսիք են ուղղումները: Բացի դրանից, Conventional Commits-ի ճկունությունը թույլ է տալիս Ձեր թիմին գտնել իրենց տեսակները և ժամանակի ընթացքում փոխել դրանք:
### Ինչպե՞ս է դա կապված SemVer-ի հետ:
`fix` տեսակի պարտավորությունները պետք է թարգմանվեն `PATCH` թողարկումներով: `feat` տեսակի պարտավորությունները պետք է թարգմանվեն `MINOR` թողարկումներով: Հանձնարարություններում `BREAKING CHANGE` ունեցող պարտավորությունները, անկախ տեսակից, պետք է թարգմանվեն `MAJOR` թողարկումներով:
### Ինչպես պետք է տարբերակեմ իմ ընդլայնումները Conventional Commits-ի սպեցիֆիկացիայի համար (օրինակ `@jameswomack/conventional-commit-spec`):
Մենք խորհուրդ ենք տալիս օգտագործել SemVer-ը, որպեսզի թողարկեք ձեր սեփական ընդլայնումները այս բնութագրին (և
խրախուսում ենք ձեզ կատարել այս ընդլայնումները:)
### Ի՞նչ անեմ, եթե պատահաբար օգտագործեմ սխալ commit-ի տեսակը:
#### Երբ դուք օգտագործում եք այնպիսի տեսակ, որը համապատասխանում է բնութագրին, բայց ոչ ճիշտ, օրինակ. `fix`՝ `feat`-ի փոխարեն
Նախքան սխալը միաձուլելը կամ բաց թողնելը, մենք խորհուրդ ենք տալիս օգտագործել `git rebase -i`՝ կատարման պատմությունը խմբագրելու համար: Թողարկումից հետո մաքրումը կտարբերվի՝ կախված ձեր օգտագործած գործիքներից և գործընթացներից:
#### Երբ դուք օգտագործում եք հատուկ *ոչ* տեսակ, օրինակ. `feet`՝ `feat`-ի փոխարեն
Վատագույն սցենարի դեպքում աշխարհի վերջը չէ, եթե commit-ը վայրէջք կատարի, որը չի համապատասխանում Conventional Commits-ի պահանջներին: Դա պարզապես նշանակում է, որ commit-ը բաց կթողնի այն գործիքները, որոնք հիմնված են բնութագրերի վրա:
### Արդյո՞ք իմ բոլոր մասնակիցները պետք է օգտագործեն Conventional Commits-ի հստակեցումը:
Ո՛չ։ Եթե դուք օգտագործում եք squash-ի վրա հիմնված աշխատանքային հոսք Git-ի առաջատար սպասարկիչները կարող են մաքրել commit հաղորդագրությունները, քանի որ դրանք միաձուլվում են՝ առանց աշխատանքային ծանրաբեռնվածության ավելացման պատահական commiter-ին:
Սրա համար ընդհանուր աշխատանքային հոսքն այն է, որ ձեր git համակարգը ինքնաբերաբար PR-ը կմիաձուլի մեկ squash commit-ի մեջ, որպեսզի առաջատար սպասարկիչը մուտքագրի համապատասխան git commit հաղորդագրությունը միաձուլման համար:
### Ինչպե՞ս են Conventional Commits-ը վերաբերվում վերադարձի(revert) commit-ներին:
Կոդը վերադարձնելը կարող է բարդ լինել. դուք վերադարձնու՞մ եք մի քանի commit-ներ: եթե վերադարձնեք որևէ հատկանիշ(feature), հաջորդ թողարկումը դրա փոխարեն կարկատա՞կ պետք է լինի:
Conventional Commits-ը բացահայտ ջանքեր չի գործադրում հետադարձ վարքագիծը սահմանելու համար: Փոխարենը թողնում ենք
հեղինակներին օգտագործել _types_-ի և _footers_-ի ճկունությունը՝ զարգացնելու իրենց տրամաբանությունը հետադարձումների հետ աշխատելու համար:
Առաջարկություններից մեկն է օգտագործել `revert` տիպը և վերջավորություն, որը հղում է կատարում վերադարձվող SHA-ներին՝
```
revert: let us never again speak of the noodle incident
Refs: 676104e, a215868
```
================================================
FILE: content/v1.0.0/index.id.md
================================================
---
draft: false
aliases: ["/id/"]
---
# Conventional Commits 1.0.0
## Ringkasan
Conventional Commits adalah perjanjian sederhana tentang cara menulis pesan komit.
Ini menjelaskan sekumpulan aturan sederhana untuk membuat riwayat komit yang jelas;
yang memudahkan untuk membuat alat otomatis di atasnya.
Perjanjian ini sesuai dengan [SemVer](http://semver.org/lang/id/),
dengan menjelaskan suatu fitur (features), perbaikan (fixes), perubahan yang merusak (breaking changes) yang dimuat dalam pesan komit.
Pesan komit harus tersusun sebagai berikut:
---
```
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
```
---
<br />
Komit ini memiliki elemen-elemen struktural berikut untuk menjelaskan maksud kepada pengguna pustaka:
1. **fix:** komit _tipe_ `fix` untuk perbaikan celah (bug) dalam kode Anda (ini berkaitan dengan [`PATCH`](http://semver.org/#summary) di Semantic Versioning).
1. **feat:** komit _tipe_ `feat` memperkenalkan suatu fitur (feature) baru dalam kode Anda (ini berkaitan dengan [`MINOR`](http://semver.org/#summary) di Semantic Versioning).
1. **BREAKING CHANGE:** komit yang berisi footer `BREAKING CHANGE:`, atau tambahkan `!` setelah type/scope, memperkenalkan perubahan yang merusak API (ini berkaitan dengan [`MAJOR`](http://semver.org/#summary) di Semantic Versioning). BREAKING CHANGE dapat diterapkan pada semua _tipe_ komit.
1. _types_ selain `fix:` dan `feat:` diperbolehkan, sebagai contoh [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (berdasarkan pada [the Angular convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) disarankan `build:`, `chore:`,
`ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, dan lainnya.
1. _footers_ daripada `BREAKING CHANGE: <description>` dapat disediakan dan mengikuti konvensi yang mirip dengan
[format git trailer](https://git-scm.com/docs/git-interpret-trailers).
Tipe tambahan tidak di amanatkan oleh spesifikasi conventional commits, dan tidak ada efek implisit dalam Semantic Versioning (kecuali mereka termasuk BREAKING CHANGE).
<br /> <br />
Cakupan (scope) dapat disediakan ke tipe komit untuk memberikan informasi kontekstual tambahan dan terkandung dalam kurung, misalnya, `feat(parser): add ability to parse arrays`.
## Contoh
### Pesan komit dengan deskripsi dan breaking change di 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
```
### Pesan komit dengan `!` untuk menarik perhatian pada breaking change
```
feat!: send an email to the customer when a product is shipped
```
### Pesan komit dengan scope dan `!` untuk menarik perhatian pada breaking change
```
feat(api)!: send an email to the customer when a product is shipped
```
### Pesan komit dengan keduanya `!` dan footer BREAKING CHANGE
```
feat!: drop support for Node 6
BREAKING CHANGE: use JavaScript features not available in Node 6.
```
### Pesan komit tanpa body
```
docs: correct spelling of CHANGELOG
```
### Pesan komit dengan scope
```
feat(lang): add polish language
```
### Pesan komit dengan badan multi-paragraf dan multi-footer
```
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
```
## Spesifikasi
Kata kunci “HARUS”, “TIDAK BOLEH”, “DIBUTUHKAN”, “SEHARUSNYA”, “JANGAN SAMPAI”, “SEBAIKNYA”, “SEBAIKNYA TIDAK”, “DIREKOMENDASIKAN”, “BISA”, dan “OPSIONAL” di dokumen ini sesuai dengan [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
1. Komit HARUS (MUST) diawali dengan tipe, yang terdiri dari kata benda, `feat`, `fix`, dll., diikuti dengan scope OPSIONAL (OPTIONAL) `!`, dan DIBUTUHKAN (REQUIRED) terminal colon dan spasi.
1. Tipe `feat` HARUS (MUST) digunakan ketika komit menambahkan fitur baru ke aplikasi atau pustaka Anda.
1. Tipe `fix` HARUS (MUST) digunakan ketika komit merepresentasikan perbaikan bug untuk aplikasi Anda.
1. Scope BISA (MAY) dicantumkan setelah tipe. Scope HARUS (MAY) terdiri dari kata benda yang menggambarkan bagian dari kode yang dikelilingi tanda kurung, misalnya, e.g., `fix(parser):`
1. Deskripsi HARUS (MUST) segera mengikuti spasi setelah awalan type/scope. Deskripsi adalah ringkasan singkat dari perubahan kode, misalnya, _fix: array parsing issue when multiple spaces were contained in string_.
1. Body yang lebih panjang BISA (MAY) disediakan setelah deskripsi singkat, memberikan informasi kontekstual tambahan tentang perubahan kode. Body HARUS (MUST) memulai satu baris kosong setelah deskripsi.
1. Body komit adalah bentuk bebas dan BISA (MAY) terdiri dari sejumlah paragraf terpisah baris baru.
1. Satu atau lebih footer BISA (MAY) disediakan satu baris kosong setelah badan. Setiap footer HARUS (MUST) terdiri dari token kata, diikuti oleh pemisah `:<space>` atau `<space>#`, diikuti oleh nilai string (ini terinspirasi oleh [git trailer convention](https://git-scm.com/docs/git-interpret-trailers)).
1. Token footer HARUS (MUST) menggunakan `-` sebagai ganti karakter spasi putih, mis., `Acked-by` (ini membantu membedakan bagian footer dari badan multi-paragraf). Pengecualian dibuat untuk `BREAKING CHANGE`, yang BISA (MAY) juga digunakan sebagai token.
1. Nilai footer BISA (MAY) berisi spasi dan baris baru, dan penguraian HARUS (MUST) berakhir ketika pasangan token/pemisah footer yang berlaku berikutnya diamati.
1. Melanggar perubahan HARUS (MUST) ditunjukkan dalam tipe / lingkup awalan dari komit, atau sebagai entri dalam catatan kaki.
1. Jika dimasukkan sebagai footer, perubahan yang melanggar HARUS (MUST) terdiri dari teks huruf besar BREAKING CHANGE, diikuti oleh titik dua, spasi, dan deskripsi, mis., _BREAKING CHANGE: variabel lingkungan sekarang diutamakan daripada file konfigurasi_.
1. Jika termasuk dalam
awalan, memecah perubahan HARUS (MUST) ditunjukkan oleh `!` Segera sebelum `:`. Jika `!` Digunakan, `BREAKING CHANGE:` BISA (MAY) dihapus dari bagian footer, dan deskripsi commit HARUS (MUST) digunakan untuk menjelaskan perubahan yang melanggar.
1. Jenis selain `feat` dan `fix` BISA (MAY) digunakan dalam pesan komit Anda, mis., _docs: updated ref docs._
1. Unit-unit informasi yang membentuk konvensional melakukan TIDAK BOLEH (MUST NOT) diperlakukan sebagai case sensitif oleh implementor, dengan pengecualian BREAKING CHANGE yang HARUS (MUST) huruf besar.
1. BREAKING-CHANGE HARUS (MUST) identik dengan BREAKING CHANGE, bila digunakan sebagai token di footer.
## Mengapa menggunakan Conventional Konvensional
* Secara otomatis menghasilkan CHANGELOGs.
* Secara otomatis menentukan versi semantic (Berdasarkan tipe komit yang dilakukan).
* Mengomunikasikan sifat perubahan kepada rekan setim, publik, dan pemangku kepentingan lainnya.
* Memicu proses pembuatan dan publikasi.
* Mempermudah orang untuk berkontribusi pada proyek Anda, dengan memungkinkan mereka untuk menjelajah riwayat komit yang lebih terstruktur.
## FAQ
### Bagaimana saya harus berurusan dengan pesan komit pada fase pengembangan awal?
Kami menyarankan Anda melanjutkan seolah-olah Anda sudah merilis produk. Biasanya *seseorang*, bahkan jika itu sesama pengembang perangkat lunak Anda, menggunakan perangkat lunak Anda. Mereka ingin tahu apa yang diperbaiki, apa yang rusak, dll.
### Apakah tipe dalam komit menggunakan judul huruf besar atau kecil?
Casing apa pun dapat digunakan, tetapi yang terbaik adalah konsisten.
### Apa yang harus saya lakukan jika komit sesuai dengan lebih dari satu tipe komit?
Kembalilah dan buat beberapa komit kapan pun memungkinkan. Bagian dari manfaat Conventional Commits adalah kemampuannya mendorong kami untuk membuat komitmen dan PR yang lebih terorganisir.
### Tidakkah ini menghambat pengembangan yang cepat dan iterasi yang cepat?
Ini mencegah bergerak cepat dengan cara yang tidak teratur. Ini membantu Anda dapat bergerak cepat jangka panjang di berbagai proyek dengan kontributor yang bervariasi.
### Mungkinkah Komitmen Konvensional membuat pengembang membatasi jenis komitmen yang mereka buat karena mereka akan memikirkan jenis yang disediakan?
Komitmen Konvensional mendorong kita untuk membuat lebih banyak jenis komitmen tertentu seperti perbaikan. Selain itu, fleksibilitas Komitmen Konvensional memungkinkan tim Anda untuk membuat tipe mereka sendiri dan mengubah tipe-tipe itu seiring waktu.
### Bagaimana ini berhubungan dengan SemVer?
Komit tipe `fix` harus diterjemahkan ke rilis `PATCH`. Komit tipe `feat` harus diterjemahkan ke rilis `MINOR`. Komit dengan `BREAKING CHANGE` dalam komit, apa pun jenisnya, harus diterjemahkan ke rilis `MAJOR`.
### Bagaimana cara saya memberi versi ekstensi saya ke Spesifikasi Komitmen Konvensional, mis. `@jameswomack/commit-spec-konvensional`?
Kami sarankan menggunakan SemVer untuk merilis ekstensi Anda sendiri ke spesifikasi ini (dan
mendorong Anda untuk membuat ekstensi ini!)
### Apa yang harus saya lakukan jika saya secara tidak sengaja menggunakan tipe komit yang salah?
#### Saat Anda menggunakan jenis yang memiliki spesifikasi tetapi bukan jenis yang benar, misalnya, `fix` bukan `feat`
Sebelum menggabungkan atau merilis kesalahan, sebaiknya gunakan `git rebase -i` untuk mengedit riwayat komit. Setelah rilis, pembersihan akan berbeda sesuai dengan alat dan proses apa yang Anda gunakan.
#### Saat Anda menggunakan jenis *bukan* spesifikasi, mis. `feet` bukannya `feat`
Dalam skenario terburuk, hal ini bukanlah masalah besar jika terdapat komit yang tidak memenuhi spesifikasi conventional commit. Ini berarti komit akan dilewatkan oleh alat yang didasarkan pada spesifikasi.
### Apakah semua kontributor saya perlu menggunakan spesifikasi commit konvensional?
Tidak! Jika Anda menggunakan alur kerja berbasis squash di pengelola Git dapat membersihkan pesan komit saat mereka digabung — menambahkan tidak ada beban kerja ke committers biasa.
Alur kerja umum untuk ini adalah membuat sistem git Anda secara otomatis squash melakukan dari permintaan tarikan dan menyajikan formulir bagi pengelola utama untuk memasukkan pesan git commit yang tepat untuk penggabungan.
### Bagaimana Komit Konvensional menangani komit balik?
Mengembalikan kode bisa rumit: apakah Anda mengembalikan banyak komit? jika Anda mengembalikan fitur, haruskah rilis berikutnya sebagai tambalan?
Conventional Commits tidak membuat upaya eksplisit untuk mendefinisikan perilaku kembalikan. Alih-alih, kami menyerahkannya kepada perkakas penulis untuk menggunakan fleksibilitas _type_ dan _footers_ untuk mengembangkan logika mereka untuk menangani orang yang kembali.
Satu rekomendasi adalah menggunakan tipe `revert`, dan _footer_ yang merujuk komit SHA yang sedang dikembalikan:
```
revert: let us never again speak of the noodle incident
Refs: 676104e, a215868
```
================================================
FILE: content/v1.0.0/index.it.md
================================================
---
draft: false
aliases: ["/it/"]
---
# Commit Convenzionali 1.0.0
## Riepilogo
La specifica Conventional Commits è una convenzione semplice da implementare per i messaggi dei commit.
Fornisce un insieme di semplici regole per la creazione di una cronologia di commit esplicita;
il che rende più facile utilizzare strumenti per automatizzare processi.
Questa convenzione si completa con [SemVer](http://semver.org/lang/it/),
descrivendo le funzionalità, la risoluzione di errori e l'introduzione di breaking changes fatte dei commit.
I messaggi dei commit dovrebbero seguire la seguente struttura:
---
```
<tipo>[contesto opzionale]: <descrizione>
[corpo opzionale]
[piè di pagina opzionali]
```
---
<br />
Il commit contiene i seguenti elementi strutturali, allo scopo di comunicare l'intento al consumatore della libreria:
1. **fix:** un commit di _tipo_ `fix` risolve un errore nel codice (correlato al [`PATCH`](http://semver.org/#summary) in un versionamento Semver).
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 in un _piè di pagina_ `BREAKING CHANGE:`, o aggiunge un `!` subito dopo il _tipo_/_contesto_, 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. 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/22b96b9/CONTRIBUTING.md#-commit-message-guidelines))
raccomanda `build:`, `chore:`, `ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, ed altri.
1. Altri _piè di pagina_ oltre `BREAKING CHANGE: <description>` possono essere utilizzati e seguono ua specifica simile a [git trailer format](https://git-scm.com/docs/git-interpret-trailers).
Altri _tipi_ non sono mantenuti da questa specifica, e non hanno un effetto sul versionamento semver (a meno che non introducano una _BREAKING CHANGE_).
<br />
Un _contesto_ potrebbe essere aggiunto al _tipo_ di commit, al fine di offrire ulteriori informazioni contestuali.
Da aggiungere tra delle parentesi tonde, Es: `feat(parser): add ability to parse arrays`.
## Esempi
### Messaggio di un commit con una _descrizione_ e una breaking change nel _piè di pagina_
```
feat: allow provided config object to extend other configs
BREAKING CHANGE: `extends` key in config file is now used for extending other config files
```
### Messaggio di un commit con un `!` per attirare l'attenzione su una breaking change
```
feat!: send an email to the customer when a product is shipped
```
### Messaggio di un commit con uno contesto e `!` per attirare attenzione ad una breaking change
```
feat(api)!: send an email to the customer when a product is shipped
```
### Messaggio di un commit con entrambe `!` e _BREAKING CHANGE_ a piè di pagina
```
feat!: send an email to the customer when a product is shipped
BREAKING CHANGE: dropping Node 6 which hits end of life in April
```
### Messaggio di un commit senza una _descrizione_
```
docs: correct spelling of CHANGELOG
```
### Messaggio di un commit con uno _contesto_
```
feat(lang): added polish language
```
### Messaggio di un commit per un `fix` utilizzando il numero della issue (opzionale)
```
fix: minor typos in code
see the issue for details on the typos fixed
Reviewed-by: Z
Refs: #133
```
## Specifica
Le parole “DEVE”, “NON DEVE”, “RICHIESTO”, “DOVRÀ”, “NON DOVRÀ”, “DOVREBBE”, “NON DOVREBBE”, “RACCOMANDATO”, “POTREBBE” e “OPZIONALE” devo essere interpretata come da specifica [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
1. Un commit DEVE iniziare con un _tipo_, il quale consiste in un sostantivo, `feat`, `fix`, etc., seguito da un OPZIONALE `!`, e DEVE essere seguito dai due punti ed uno spazio.
1. Il _tipo_ `feat` DEVE essere usato quando un commit aggiunge una funzionalità all'applicazione o libreria.
1. Il _tipo_ `fix` DEVE essere usato quando un commit corregge un errore all'applicazione o libreria.
1. Un _contesto_ opzionale POTREBBE essere fornito dopo il _tipo_.
Un _contesto_ rappresenta una sezione dell'applicazione o della libreria, il contenuto va racchiuso tra parentesi.
Es: `fix(parser):`
1. Una _descrizione_ DEVE seguire immediatamente i due punti dopo il _tipo_ (con eventuale _contesto_).
Per _descrizione_ si intende una breve spiegazione riguardo la modifica al codice.
Es: _fix: array parsing issue when multiple spaces were contained in string_.
1. Un _corpo_ del commit più lungo POTREBBE essere aggiunto dopo una breve _descrizione_, aggiungendo ulteriori informazioni contestuali riguardo le modifiche apportate al codice.
Il _corpo_ DEVE iniziare dopo una linea vuota dalla _descrizione_.
1. Un _corpo_ può contenere qualsiasi contenuto e POTREBBE essere formato da qualsiasi numero di linee separate.
1. Uno o più _pié di pagina_ POTREBBERO essere usati dopo una linea vuota dallo _spazio_.
Ogni _piè di pagina_ DEVE avere una parola chiave seguita da `:<space>` o `<space>#`, poi seguita da un _token_ (ispirato a
[git trailer convention](https://git-scm.com/docs/git-interpret-trailers)).
1. Un _token_ DEVE usare `-` al posto degli spazi, ad esempio, `Acked-by` (questo serve a distinguere _piè di pagina_ e _corpo_).
Un eccezione è fatta per `BREAKING CHANGE`, ch POTREBBE essere utilizzata come _token_.
1. Un _piè di pagina_ POTREBBE contenere spazi e linee vuote, and DEVE finire quando si incontra il _token_.
1. Una _breaking changes_ DEVE essere indicata dopo il _tipo_/_contesto_ come `!`, all'inizio delle sezioni _piè di pagina_ o del _corpo_ del commit.
Una _breaking change_ DEVE essere scritta in maiuscolo `BREAKING CHANGE`, seguita dai due punti ed uno spazio.
1. Una descrizione DEVE essere aggiunta dopo il testo `BREAKING CHANGE: `, descrivendo il cambiamento delle API.
Es: _BREAKING CHANGE: environment variables now take precedence over config files._
1. Un `!` POTREBBE essere aggiunti prima del prefisso`:` nel _tipo_/_contesto_, per attirare notificare l'introduzione di una breaking change. `BREAKING CHANGE: description` DEVE essere aggiungto nel _copro_ o _piè di pagina_ se un `!` è presente.
1. Un commit POTREBBE utilizzare altri _tipi_ al di fuori di `feat` e `fix` nel messaggio.
1. La convenzione NON DEVE tener conto del maiuscolo o minuscolo, ad eccezione di `BREAKING CHANGE` che DEVE sempre essere maiuscolo.
1. `BREAKING-CHANGE` equivale a `BREAKING CHANGE`
## Perchè utilizzare commit convenzionali
* CHANGELOG generati automaticamente.
* Determina automaticamente l'incremento di un versionamento semver (basandosi sui tipi di commit utilizzati).
* Comunica la natura dei cambiamenti a colleghi, pubblico, o altri parti interessate.
* Attiva build e processi di rilascio.
* Rendi più semplice alle persone contribuire al tuo progetto, dando la possibilità di esplorare una cronologia di commit più strutturata.
## FAQ
### Come dovrei comportarmi con i messaggi dei commit nella fase iniziale del progetto?
Raccomandiamo di procedere come se il tuo prodotto sia già stato rilasciato. Tipicamente *qualcuno*, anche i tuoi colleghi, stanno utilizzando il tuo software. Loro vorranno sapere cosa sia stato risolto, cosa si sia rotto etc.
### I _tipi_ devono essere in maiuscolo o minuscoli?
Si possono utilizzare entrambi, ma si raccomanda di essere consistenti ed utilizzarne solamente uno.
### Cosa faccio se il tipo di commit è conforme a più di un tipo?
Torna indietro e dividi in più commit dove puoi. Parte del beneficio di usare Commit Convenzionali è quello di spingerti a fare commit e pull request organizzate meglio.
### Non scoraggia sviluppo ed iterazioni rapidi?
Scoraggia a farlo in una maniere disorganizzata. Inoltre ti aiuterà a muoverti più velocemente su più progetti con diversi contributori.
### Potrebbe Commit Convenzionali limitare gli sviluppatori a fare solamente alcuni tipi commit perchè penseranno nei tipi forniti dalla specifica?
Commit Convenzionali ti incoraggia nel fare più di certi tipi di commit. Inoltre la flessibilità di Commit Convenzionali consente al tuo team di inventare i propri tipi e cambiarli nel tempo.
### Come si collega a SemVer?
I commit di tipo `fix` dovrebbero essere traducibili ai rilasci `PATCH`.
I commit di tipo `feat` dovrebbero essere traducibili ai rilasci `MINOR`.
I commit con `BREAKING CHANGE`, indipendentemente dal tipo, dovrebbero essere traducibili ai rilasci `MAJOR`.
### Come dovrei versionare le mie estensioni per la specifica Commit Convenzionali? (Es: `@jameswomack/conventional-commit-spec`)
Raccomandiamo l'utilizzo di SemVer per rilasciare la tua estensione (crea delle estensioni!)
### Cosa faccio se accidentalmente utilizzo un tipo di commit sbagliato?
#### Quando usi un tipo della specifica ma non quello giusto (Es: `fix` invece di `feat`)
Se ancora devi creare il merge o il rilascio dell'errore, raccomandiamo l'utilizzo di `git rebase -i` per riscrivere la cronologia dei commit. Nel caso ti abbia già rilasciato questa correzione dipende dai tool e processi che usi.
#### Quando usi un tipo *non* della specifica (Es: `feet` invece di `feat`)
Non è la fine del mondo se un commit non segue la specifica Commit Convenzionali. Semplicemente il commit verrà ignorato dai tool che sono basati su questa specifica.
### Devono tutti i contributori seguire la specifica Commit Convenzionali?
No. Se usi un workflow basato sugli squash di Git, i mantenitori possono pulire i messaggi dei commit mentre vengono inseriti nel branch principale (merge), non aggiungendo alcun carico di lavoro ai committer occasionali. Un workflow comune è quello di unire (con lo squash) automaticamente i commit dalle pull request e far utilizzare un form ai mantenitori per riscrivere un messaggio più adeguato.
================================================
FILE: content/v1.0.0/index.ja.md
================================================
---
draft: false
aliases: ["/ja/"]
---
# Conventional Commits 1.0.0
## 概要
Conventional Commits の仕様はコミットメッセージのための軽量の規約です。
明示的なコミット履歴を作成するための簡単なルールを提供します。この規則に従うことで自動化ツールの導入を簡単にします。
コミットメッセージで機能追加・修正・破壊的変更などを説明することで、この規約は [SemVer](http://semver.org/lang/ja/) と協調動作します。
コミットメッセージは次のような形にする必要があります:
---
原文：
```
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
```
訳：
```
<型>[任意 スコープ]: <タイトル>
[任意 本文]
[任意 フッター]
```
---
<br />
あなたのライブラリの利用者に意図を伝えるために、コミットは以下の構造化された要素を持ちます：
1. **fix:** _型_ `fix` を持つコミットはコードベースのバグにパッチを当てます (これは Semantic Versioning における [`PATCH`](http://semver.org/#summary) に相当します)。
1. **feat:** _型_ `feat` を持つコミットはコードベースに新しい機能を追加します (これは Semantic Versioning における [`MINOR`](http://semver.org/#summary) に相当します)。
1. **BREAKING CHANGE:** _フッター_ に `BREAKING CHANGE:` が書かれているか型/スコープの直後に `!` が追加されているコミットは API の破壊的変更を導入します (Semantic Versioning における [`MAJOR`](http://semver.org/#summary) に相当します)。
`BREAKING CHANGE` は任意の _型_ のコミットに含めることができます。
1. `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:`, などを推奨しています。
1. [git trailer format](https://git-scm.com/docs/git-interpret-trailers) に似た規約に従って、`BREAKING CHANGE: <タイトル>` 以外の _フッター_ が与えられるかもしれません。
追加の型たちは Conventional Commits の仕様で義務付けられているものではなく、(BREAKING CHANGE を含まない限り) Semantic Versioning に対する暗黙的な効果を持ちません。
<br /><br />
コミットの型には追加の文脈の情報として _スコープ_ を追加することができます。スコープは括弧で囲みます。たとえば `feat(parser): add ability to parse arrays` のようになります。
## 例
### タイトルおよび破壊的変更のフッターを持つコミットメッセージ
```
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
```
### `!` と BREAKING CHANGE フッターの両方を持つコミットメッセージ
```
feat!: drop support for Node 6
BREAKING CHANGE: use JavaScript features not available in Node 6.
```
### 本文を持たないコミットメッセージ
```
docs: correct spelling of CHANGELOG
```
### スコープを持つコミットメッセージ
```
feat(lang): add polish language
```
### 複数段落からなる本文と複数のフッターを持ったコミットメッセージ
```
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) ([JPNIC 日本語訳](https://www.nic.ad.jp/ja/tech/ipa/RFC2119JA.html)) で述べられているように解釈されるべきものです。
1. コミットは `feat` や `fix` などの型から始まり (MUST)、その後ろにはスコープ (OPTIONAL) と `!` (OPTIONAL) が続き、その後ろにコロンとスペース (REQUIRED) が続く。
1. コミットがあなたのアプリケーションやライブラリに新しい機能を追加するとき、型 `feat` が使われなければならない (MUST)。
1. コミットがあなたのアプリケーションのためのバグ修正を行うとき、型 `fix` が使われなければならない (MUST)。
1. スコープを型の後ろに記述してもよい (MAY)。スコープは、コードベースのセクションを記述する括弧で囲まれた名詞にしなければならない (MUST)。例: `fix(parser):`。
1. 型/スコープの後ろのコロンとスペースの直後にタイトルが続かなければならない (MUST)。
タイトルはコード変更の短かい要約である。例: `fix: array parsing issue when multiple spaces were contained in string`。
1. 短いタイトルの後ろにより長いコミットの本文を追加してもよい (MAY)。これはコード変更に関する追加の情報を提供する。
本文はタイトルの下の 1 行の空行から始めなければならない (MUST)。
1. コミットの本文は自由な形式であり、改行で区切られた複数の段落で構成することができる (MAY)。
1. ひとつ以上のフッターを、本文の下の 1 行の空行に続けて書くことができる (MAY)。
それぞれのフッターは、ひとつの単語トークン、それに続く `:<space>` か `<space>#` によるセパレータ、そして文字列の値から構成されなければならない (MUST) (これは [git trailer convention](https://git-scm.com/docs/git-interpret-trailers) に触発されている)。
1. フッターのトークンは空白の代わりに `-` を使わなければならない (MUST)。例えば `Acked-by` とする (これは複数段落からなる本文からフッターを区別するのに役立つ)。
例外として `BREAKING CHANGE` があり、これをトークンとして使用することができる (MAY)。
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. `feat` と `fix` 以外の型を使うことができる (MAY)。例: `docs: updated ref docs.`。
1. Conventional Commits を構成する情報の単位は、大文字の `BREAKING CHANGE` を除いて、実装は大文字と小文字を区別してはならない (MUST NOT)。
1. フッターのトークンにおいて BREAKING-CHANGE は BREAKING CHANGE と同じトークンとして解釈されなければならない (MUST)。
## 何故 Conventional Commits を使うのか
* 変更履歴 (CHANGELOG) を自動的に生成できます。
* semantic version 単位で自動的に履歴をまとめられます (コミットの型に基づきます)。
* チームメイトや一般のユーザー、およびその他の利害関係者へ変更の内容を伝えることができます。
* ビルドや公開の処理をトリガーできます。
* より構造化されたコミット履歴を調査できるようにすることで、人々があなたのプロジェクトに貢献しやすくなります。
## よくある質問
### 初期の開発段階ではコミットメッセージをどのように扱うべきですか？
すでに製品をリリースしているかのように進めることをお勧めします。
あなたの仲間のソフトウェア開発者であっても、普通は *誰か* があなたのソフトウェアを使っています。
何が修正されたのかや何が壊れたのかなどを彼らは知りたいでしょう。
### コミットタイトル (1 行目) の型は大文字か小文字のどちらがよいですか？
どちらでも問題はありませんが、一貫性を保つべきです。
### コミットが複数のコミット型からなるような場合はどうすればよいですか？
可能な限り、引き返して複数のコミットに分割します。
Conventional Commits の利点のひとつは、より組織化されたコミットとプルリクエストを行う事を可能にする事です。
### これは開発速度とインテグレーションを遅くしたりはしませんか？
無秩序にただ早く開発することはお勧めではありません。
これはあなたがさまざまな貢献者との複数のプロジェクト間で長期的に素早く動けるようにするのを助けます。
### Conventional Commits では開発者は与えられた型の中で考える必要があるため、作ることのできるコミットの種類が制限されてしまうのではありませんか？
Conventional Commits は `fix` などの特定の型を持つコミットを作るように促します。
それ以外には、Conventional Commits の柔軟性は、あなたのチームが独自の型を提案し作り、また時間の経過とともにそれらの型を変更していくことを許します。
### これは SemVer とどのような関係を持っていますか？
`fix` 型のコミットは `PATCH` リリースへ変換されます。`feat` 型のコミットは `MINOR` リリースへ変換されます。型にかかわらずコミット内で `BREAKING CHANGE` を使ったコミットは `MAJOR` リリースに変換されるべきでしょう。
### Conventional Commits の仕様についての私の拡張はどのようにバージョンを振るべきでしょうか？ 例: `@jameswomack/conventional-commit-spec`
SemVer を使用して、この仕様に対する独自の拡張をリリースすることをお勧めします (そしてそのような拡張仕様の作成を推奨します！)。
### 間違ったコミット型を使用してしまった時はどうしたらいいですか？
#### 仕様的に正しい型だが意味的に間違った型を使用した場合、たとえば `feat` の代わりに `fix`
間違いをマージやリリースする前に、`git rebase -i` を使ってコミット履歴を編集することをお勧めします。
リリース後であれば、どのようなツールやプロセスを使用しているかによって後始末は異なってくるでしょう。
#### 仕様に *ない* 型を使った場合、例えば `feat` ではなく `feet`
最悪のシナリオはコミットが Conventional Commits の仕様を満たさない場合です。しかしそれは世界の終わりではありません。
それは単に仕様に基づいているツールによってコミットが見逃されるだけでしかありません。
### 貢献者全員が Conventional Commits の仕様を使用する必要がありますか？
いいえ！ Git で squash ベースのワークフローを使用する場合は、主要メンテナがマージ時にコミットメッセージをクリーンアップすることができるため、臨時のコミッタには作業負荷がかかりません。
また、これをするための一般的な方法としては、プルリクエストからのコミットを git システムが自動的に squash し、主要メンテナによるマージ時に適切な git コミットメッセージを入力するためのフォームを表示するというものです。
### Conventional Commits は `revert` コミットをどのように扱いますか？
コードを revert するのは複雑な場合があります。
複数のコミットを revert しますか？ 機能を revert するとき、次のリリースはただのパッチでしょうか？
Conventional Commits は revert の振る舞いを定義するための明示的な努力をしません。
その代わりに、revert を処理するためのロジックを型とフッターの柔軟性を利用して開発するようなツールの作者に、これを任せます。
我々のおすすめの方法としては、ひとつは `revert` 型と revert されるコミットの SHA を参照するフッターを使うようにすることです。
```
revert: let us never again speak of the noodle incident
Refs: 676104e, a215868
```
================================================
FILE: content/v1.0.0/index.ko.md
================================================
---
draft: false
aliases: ["/ko/"]
---
# Conventional Commits 1.0.0
## 개요
Conventional Commits 스펙은 커밋 메시지에 곁들여진 가벼운 컨벤션으로 명확한 커밋 히스토리를 생성하기 위한 간단한 규칙을 제공합니다. 이렇게 만들어진 커밋 히스토리를 이용하여 더 쉽게 자동화된 도구를 만들 수 있습니다.
이 컨벤션은 커밋 메시지에 신규 기능 추가, 문제 수정, 커다란 변화가 있음을 기술함으로써 [유의적 버전(Sementic Versioning)](https://semver.org/lang/ko/)과 일맥상통한 면이 있습니다.
커밋 메시지는 다음과 같은 구조가 되어야 합니다:
---
```
<타입>[적용 범위(선택 사항)]: <설명>
[본문(선택 사항)]
[꼬리말(선택 사항)]
```
---
<br />
커밋에는 라이브러리를 사용하는 사람들에게 의도를 전달하기 위해 다음과 같은 구조적 요소가 포함되어 있습니다.
1. **fix:** 코드베이스에서 버그를 패치하는 `fix` _타입_ 의 커밋 (이는 유의적 버전에서의 [`PATCH`](http://semver.org/#summary)와 관련이 있습니다).
1. **feat:** 코드베이스에서 새 기능이 추가되는 `feat` _타입_ 의 커밋 (이는 유의적 버전에서의 [`MINOR`](http://semver.org/#summary)와 관련이 있습니다).
1. **BREAKING CHANGE:** `BREAKING CHANGE:`이라는 꼬리말을 가지거나 타입/스코프 뒤에 !문자열을 붙인 커밋은 단절적 API 변경(breaking API change)이 있다는 것을 의미합니다 (이는 유의적 버전에서의 [`MAJOR`](http://semver.org/#summary)와 관련이 있습니다). 어떤 커밋 타입이라도 BREAKING CHANGE는 해당 커밋의 일부가 될 수 있습니다.
1. `fix:`와 `feat:` 이외의 다른 _타입_ 도 허용됩니다. 예를 들어 [앵귤러 컨벤션](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)을 기반으로 하는 [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional)에서는 `build:`, `chore:`, `ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:` 등의 타입을 사용할 것을 권고하고 있습니다.
1. `BREAKING CHANGE:<description>` 이외의 _꼬리말_ 을 규정 할 수 있으며 다음과 비슷한 컨벤션을 따를 수 있습니다. [git trailer format](https://git-scm.com/docs/git-interpret-trailers).
추가 타입들은 컨벤션 커밋 규격에 의해 의무화되지 않으며, 유의적 버전에 잠재적인 영향을 주지 않습니다(그것이 BREAKING CHANGE를 포함하지 않는 한).
<br /><br />
추가적인 문맥 정보를 제공하기 위한 목적으로 사용되는 적용 범위는 커밋의 타입에 덧붙여질 수 있는데 괄호 안에 포함됩니다, 예를 들면, `feat(parser): add ability to parse arrays`.
<br />
## 예제
### 설명과 BREAKING CHANGE 꼬리말을 가지는 커밋 메시지
```
feat: allow provided config object to extend other configs
BREAKING CHANGE: `extends` key in config file is now used for extending other config files
```
### 단절적 변경(breaking change)에 주의를 주기 위해 `!`를 포함한 커밋 메시지
```
feat!: send an email to the customer when a product is shipped
```
### 단절적 변경(breaking change)에 주의를 주기 위해 적용 범위와 `!` 를 포함한 커밋 메시지
```
feat(api)!: send an email to the customer when a product is shipped
```
### BREAKING CHANGE 꼬리말과 `!`를 함께 포함한 커밋 메시지
```
feat!: drop support for Node 6
BREAKING CHANGE: use JavaScript features not available in Node 6.
```
### 본문이 없는 커밋 메시지
```
docs: correct spelling of CHANGELOG
```
### 적용 범위를 가지는 커밋 메시지
```
feat(lang): add polish language
```
### 다중-단락 본문과 다수의 꼬리말을 가진 커밋 메시지
```
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` 같은 명사로 된 접두어를 포함해야 하고 그 뒤로 선택 사항인 적용 범위, 선택 사항인 `!`, 그리고 필수인 `:`과 공백이 있어야 합니다.
1. `feat` 타입은 커밋에 애플리케이션이나 라이브러리에 새로운 기능이 추가될 때 사용되어야 합니다.
1. `fix` 타입은 커밋에 애플리케이션의 버그 수정을 하는 내용을 포함하는 경우에 사용되어야 합니다.
1. 적용 범위는 타입 다음에 기술하는데 이는 코드베이스가 적용되는 영역을 기술하는 명사로 괄호로 감싸져야 합니다, 예를 들어, `fix(parser):`
1. 설명은 타입/적용 범위 접두어 뒤에 있는 콜론(:)과 공백 다음에 작성되어야 합니다. 설명은 코드 변경 사항에 대한 짧은 요약입니다, 예를 들어, _fix: array parsing issue when multiple spaces were contained in string._
1. 더 긴 커밋 본문은 짧은 설명 다음에 위치할 수 있으며 코드 변경 사항에 대한 추가적인 문맥적인 정보를 제공합니다. 본문은 반드시 설명 다음에 빈 행으로 시작해야 합니다.
1. 커밋 본문은 형식이 자유로우며 새 줄로 분리된 많은 수의 단락들로 구성 될 수 있습니다.
1. 하나 또는 다수의 꼬리말들은 본문 다음 빈 행 다음에 위치합니다. 각각의 꼬리말은 반드시 단어 토큰, 그 뒤에 `:<space>` 또는 `<space>#` 구분자, 그 뒤에 문자열 값으로 구성되어야 합니다(이것은 다음에 영향을 받았습니다 [git trailer convention](https://git-scm.com/docs/git-interpret-trailers)).
1. 꼬리말의 토큰은 반드시 공백 문자 대신 `-` 를 사용해야 합니다. 예를 들면 `Acked-by` (이것은 다중-단락 본문과 꼬리말 섹션을 구분하는데 도움이 됩니다). `BREAKING CHANGE`는 예외적으로 토큰으로 사용될 수 있습니다.
1. 꼬리말의 값은 공백이나 새 줄들을 포함할 수 있으며, 구문 분석기는 다음의 유효한 꼬리말 토큰/구분자 쌍을 관찰하면 반드시 종료해야 합니다.
1. 단절적 변경은 반드시 커밋의 타입/적용범위 접두어에 표시하거나 꼬리말에 기입되어야 합니다.
1. 꼬리말로 포함된 경우 단절적 변경은 반드시 대문자 문자열 BREAKING CHANGE과 뒤따르는 콜론(:), 공백, 그리고 설명으로 구성되어야 합니다. 예를 들면 _BREAKING CHANGE: environment variables now take precedence over config files._
1. 타입/범위 접두어에 포함된 경우, 단절적 변경은 반드시 `:` 바로 앞의 `!` 를 명시해야 합니다. 만약 `!` 가 사용되면, `BREAKING CHANGE:` 는 꼬리말 섹션에서 생략할 수 있으며, 커밋 설명은 단절적 변경을 설명하기 위해 사용되어야 합니다.
1. `feat`와 `fix` 이외의 타입이 커밋 메시지에 사용될 수 있습니다. 예: _docs: updated ref docs._
1. Conventional Commit을 구성하는 정보의 단위는 반드시 대문자여야 하는 BREAKING CHANGES를 제외하고 구현자에 의해 대소문자를 구분하는 것으로 처리되어서는 안됩니다.
1. BREAKING-CHANGE는 꼬리말에서 토큰으로 사용될 때 반드시 BREAKING CHANGE와 동의어야 합니다.
## 왜 Conventional Commits를 사용할까요?
gitextract_w3upijgj/
├── .gitignore
├── .node-version
├── CODE_OF_CONDUCT.md
├── CONTRIBUTING.md
├── Dockerfile
├── Dockerfile.dev
├── LICENSE
├── Makefile
├── README.md
├── _redirects
├── archetypes/
│ ├── about.md
│ ├── next.md
│ ├── v1.0.0-beta.1.md
│ ├── v1.0.0-beta.2.md
│ ├── v1.0.0-beta.3.md
│ ├── v1.0.0-beta.md
│ └── v1.0.0.md
├── config.yaml
├── content/
│ ├── about/
│ │ └── index.md
│ ├── next/
│ │ └── index.md
│ ├── v1.0.0/
│ │ ├── index.ar.md
│ │ ├── index.be.md
│ │ ├── index.bn.md
│ │ ├── index.de.md
│ │ ├── index.es.md
│ │ ├── index.fr.md
│ │ ├── index.gr.md
│ │ ├── index.hi.md
│ │ ├── index.hy.md
│ │ ├── index.id.md
│ │ ├── index.it.md
│ │ ├── index.ja.md
│ │ ├── index.ko.md
│ │ ├── index.md
│ │ ├── index.ml.md
│ │ ├── index.nl.md
│ │ ├── index.pl.md
│ │ ├── index.pr.md
│ │ ├── index.pt-br.md
│ │ ├── index.ro.md
│ │ ├── index.ru.md
│ │ ├── index.si.md
│ │ ├── index.sr.md
│ │ ├── index.ta.md
│ │ ├── index.th.md
│ │ ├── index.tr.md
│ │ ├── index.uk.md
│ │ ├── index.uz.md
│ │ ├── index.zh-hans.md
│ │ └── index.zh-hant.md
│ ├── v1.0.0-beta/
│ │ ├── index.it.md
│ │ ├── index.md
│ │ ├── index.pl.md
│ │ └── index.zh-hans.md
│ ├── v1.0.0-beta.1/
│ │ ├── index.it.md
│ │ ├── index.md
│ │ ├── index.pl.md
│ │ └── index.zh-hans.md
│ ├── v1.0.0-beta.2/
│ │ ├── index.es.md
│ │ ├── index.fr.md
│ │ ├── index.it.md
│ │ ├── index.md
│ │ ├── index.pl.md
│ │ ├── index.ru.md
│ │ └── index.zh-hans.md
│ ├── v1.0.0-beta.3/
│ │ ├── index.es.md
│ │ ├── index.fr.md
│ │ ├── index.hy.md
│ │ ├── index.it.md
│ │ ├── index.md
│ │ ├── index.pt-br.md
│ │ ├── index.ru.md
│ │ └── index.zh-hans.md
│ └── v1.0.0-beta.4/
│ ├── index.fr.md
│ ├── index.hy.md
│ ├── index.id.md
│ ├── index.it.md
│ ├── index.ja.md
│ ├── index.ko.md
│ ├── index.md
│ ├── index.pt-br.md
│ ├── index.ru.md
│ ├── index.zh-hans.md
│ └── index.zh-hant.md
├── data/
│ └── .gitkeep
├── docker-compose.yml
├── layouts/
│ └── .gitkeep
├── static/
│ └── .gitkeep
└── themes/
└── conventional-commits/
├── .editorconfig
├── .gitignore
├── LICENSE
├── README.md
├── archetypes/
│ └── default.md
├── layouts/
│ ├── 404.html
│ ├── _default/
│ │ └── single.html
│ ├── about/
│ │ └── single.html
│ ├── partials/
│ │ ├── footer.html
│ │ ├── head.html
│ │ ├── header.html
│ │ ├── mini_welcome.html
│ │ ├── scripts.html
│ │ ├── svg-github.html
│ │ └── welcome.html
│ └── shortcodes/
│ └── banner-image.html
├── package.json
├── static/
│ ├── css/
│ │ └── scss/
│ │ ├── abstracts/
│ │ │ ├── _functions.scss
│ │ │ ├── _mixins.scss
│ │ │ ├── _variables.scss
│ │ │ └── index.scss
│ │ ├── base/
│ │ │ └── _base.scss
│ │ ├── components/
│ │ │ ├── _banner-image.scss
│ │ │ └── _dropdown.scss
│ │ ├── layout/
│ │ │ ├── _footer.scss
│ │ │ ├── _header.scss
│ │ │ └── _welcome.scss
│ │ ├── style.scss
│ │ ├── themes/
│ │ │ ├── _conventional-commits.scss
│ │ │ └── _markdown.scss
│ │ └── vendors/
│ │ └── github-markdown-css.scss
│ └── js/
│ └── index.js
└── theme.toml
SYMBOL INDEX (7 symbols across 1 files)
FILE: themes/conventional-commits/static/js/index.js
class App (line 3) | class App {
method constructor (line 4) | constructor(anchors) {
method _addEventListeners (line 9) | _addEventListeners() {
method _onPageLoaded (line 18) | _onPageLoaded() {
method onInit (line 22) | onInit() {
method addAnchorsLinks (line 27) | addAnchorsLinks() {
method removeLoadingClass (line 32) | removeLoadingClass() {
Condensed preview — 121 files, each showing path, character count, and a content snippet. Download the .json file or copy for the full structured content (691K chars).
[
{
"path": ".gitignore",
"chars": 15,
"preview": "public/\n.idea/\n"
},
{
"path": ".node-version",
"chars": 6,
"preview": "19.0.0"
},
{
"path": "CODE_OF_CONDUCT.md",
"chars": 3244,
"preview": "# Contributor Covenant Code of Conduct\n\n## Our Pledge\n\nIn the interest of fostering an open and welcoming environment, w"
},
{
"path": "CONTRIBUTING.md",
"chars": 1259,
"preview": "# How to Contribute\n\nThe contribution guideline is derived from the SlimPHP, Istanbul Code Coverage and Ruby contributio"
},
{
"path": "Dockerfile",
"chars": 321,
"preview": "FROM node:19.0.0-alpine\nWORKDIR /src/\nCOPY ./themes/conventional-commits /src/\nRUN apk add make\nRUN npm install\nRUN npm "
},
{
"path": "Dockerfile.dev",
"chars": 193,
"preview": "FROM jguyomard/hugo-builder:latest\nFROM node:19.0.0-alpine\nWORKDIR /src/\nCOPY --from=0 /usr/local/bin/hugo /usr/local/bi"
},
{
"path": "LICENSE",
"chars": 1079,
"preview": "MIT License\n\nCopyright (c) 2018 Conventional Changelog\n\nPermission is hereby granted, free of charge, to any person obta"
},
{
"path": "Makefile",
"chars": 468,
"preview": "all: compile-assets compile-site\nall-dev: compile-assets-dev serve-site-dev\n\ncompile-site:\n\techo \"Generating static webs"
},
{
"path": "README.md",
"chars": 2484,
"preview": "# ConventionalCommits.org\n\n[![Conventional Commits](https://img.shields.io/badge/Conventional%20Commits-1.0.0-%23FE5196?"
},
{
"path": "_redirects",
"chars": 14,
"preview": "/ /en/v1.0.0/\n"
},
{
"path": "archetypes/about.md",
"chars": 31,
"preview": "---\ntype: about\ndraft: true\n---"
},
{
"path": "archetypes/next.md",
"chars": 19,
"preview": "---\ndraft: true\n---"
},
{
"path": "archetypes/v1.0.0-beta.1.md",
"chars": 20,
"preview": "---\ndraft: false\n---"
},
{
"path": "archetypes/v1.0.0-beta.2.md",
"chars": 20,
"preview": "---\ndraft: false\n---"
},
{
"path": "archetypes/v1.0.0-beta.3.md",
"chars": 20,
"preview": "---\ndraft: false\n---"
},
{
"path": "archetypes/v1.0.0-beta.md",
"chars": 20,
"preview": "---\ndraft: false\n---"
},
{
"path": "archetypes/v1.0.0.md",
"chars": 20,
"preview": "---\ndraft: false\n---"
},
{
"path": "config.yaml",
"chars": 14800,
"preview": "baseURL: '/'\nlanguageCode: en-us\ntheme: conventional-commits\ndefaultContentLanguageInSubdir: true\ndefaultContentLanguage"
},
{
"path": "content/about/index.md",
"chars": 12807,
"preview": "---\ntype: about\ndraft: false\n---\n\n# About\n\nThe Conventional Commits specification is inspired by, and based heavily on, "
},
{
"path": "content/next/index.md",
"chars": 22290,
"preview": "---\ndraft: true\n---\n\n# Conventional Commits 1.0.0-next\n\n## Summary\n\nThe Conventional Commits specification is a lightwei"
},
{
"path": "content/v1.0.0/index.ar.md",
"chars": 9202,
"preview": "---\ndraft: false\naliases: [\"/ar/\"]\n---\n\n# Conventional Commits 1.0.0\n\n## الملخص\n\nمواصفة Conventional Commits هي اتفاقية "
},
{
"path": "content/v1.0.0/index.be.md",
"chars": 11330,
"preview": "---\ndraft: false\naliases: [\"/be/\"]\n---\n\n# Пагадненне аб камітах 1.0.0\n\n## Сціслы агляд\n\nСпецыфікацыя па дадаванню лёгкач"
},
{
"path": "content/v1.0.0/index.bn.md",
"chars": 14213,
"preview": "---\ndraft: false\naliases: [\"/bn/\"]\n---\n\n# প্রচলিত কমিটসমূহ ১.০.০ \nConventional Commits 1.0.0\n\n> Commit এর বাংলা অর্থ দাঁ"
},
{
"path": "content/v1.0.0/index.de.md",
"chars": 11745,
"preview": "---\ndraft: false\naliases: [\"/de/\"]\n---\n\n# Konventionelle Commits 1.0.0\n\n## Zusammenfassung\n\nDie Spezifikation für konven"
},
{
"path": "content/v1.0.0/index.es.md",
"chars": 11244,
"preview": "---\ndraft: false\naliases: [\"/es/\"]\n---\n\n# Commits Convencionales 1.0.0\n\n## Resumen\n\nLa especificación de Commits Convenc"
},
{
"path": "content/v1.0.0/index.fr.md",
"chars": 12097,
"preview": "---\ndraft: false\naliases: [\"/fr/\"]\n---\n\n# Commits Conventionnels 1.0.0\n\n## Résumé\n\nLa spécification de Commits Conventio"
},
{
"path": "content/v1.0.0/index.gr.md",
"chars": 11899,
"preview": "---\ndraft: false\naliases: [\"/gr/\"]\n---\n\n# Conventional Commits 1.0.0\n\n## Περίληψη\n\nΗ προδιαγραφή Conventional Commits εί"
},
{
"path": "content/v1.0.0/index.hi.md",
"chars": 10622,
"preview": "---\ndraft: false\naliases: [\"/hi/\"]\n---\n\n# कन्वेंशनल कमिट्स 1.0.0\n\n## Summary\n## सारांश\n\nकन्वेंशनल कमिट्स विनिर्देश कमिट "
},
{
"path": "content/v1.0.0/index.hy.md",
"chars": 11168,
"preview": "---\ndraft: false\naliases: [\"/hy/\"]\n---\n\n# Conventional Commits 1.0.0\n\n## Ամփոփում\n\nConventional Commits-ը իրենից ներկայա"
},
{
"path": "content/v1.0.0/index.id.md",
"chars": 11006,
"preview": "---\ndraft: false\naliases: [\"/id/\"]\n---\n\n# Conventional Commits 1.0.0\n\n## Ringkasan\n\nConventional Commits adalah perjanji"
},
{
"path": "content/v1.0.0/index.it.md",
"chars": 10162,
"preview": "---\ndraft: false\naliases: [\"/it/\"]\n---\n\n# Commit Convenzionali 1.0.0\n\n## Riepilogo\n\nLa specifica Conventional Commits è "
},
{
"path": "content/v1.0.0/index.ja.md",
"chars": 7252,
"preview": "---\ndraft: false\naliases: [\"/ja/\"]\n---\n\n# Conventional Commits 1.0.0\n\n## 概要\n\nConventional Commits の仕様はコミットメッセージのための軽量の規約"
},
{
"path": "content/v1.0.0/index.ko.md",
"chars": 7084,
"preview": "---\ndraft: false\naliases: [\"/ko/\"]\n---\n\n# Conventional Commits 1.0.0\n\n## 개요\n\nConventional Commits 스펙은 커밋 메시지에 곁들여진 가벼운 컨"
},
{
"path": "content/v1.0.0/index.md",
"chars": 10330,
"preview": "---\ndraft: false\naliases: [\"/en/\"]\n---\n\n# Conventional Commits 1.0.0\n\n## Summary\n\nThe Conventional Commits specification"
},
{
"path": "content/v1.0.0/index.ml.md",
"chars": 11606,
"preview": "---\ndraft: false\naliases: [\"/ml/\"]\n---\n\n# പരമ്പരാഗത കമ്മിറ്റുകൾ 1.0.0\n\n## സംഗ്രഹം\n\nകമ്മിറ്റ് സന്ദേശങ്ങൾക്ക് മുകളിലുള്ള ഒ"
},
{
"path": "content/v1.0.0/index.nl.md",
"chars": 11726,
"preview": "---\ndraft: false\naliases: [\"/nl/\"]\n---\n\n# Conventionele Commits 1.0.0\n\n## Samenvatting\n\nDe Conventionele Commits-specifi"
},
{
"path": "content/v1.0.0/index.pl.md",
"chars": 10602,
"preview": "---\ndraft: false\naliases: [\"/pl/\"]\n---\n\n# Conventional Commits 1.0.0\n\n## Podsumowanie\n\nSpecyfikacja Conventional Commits"
},
{
"path": "content/v1.0.0/index.pr.md",
"chars": 10200,
"preview": "---\ndraft: false\naliases: [\"/pr/\"]\n---\n\n# Conventional Commits 1.0.0\n\n## خلاصه\n\nمشخصات Commits Conventional یک قرارداد س"
},
{
"path": "content/v1.0.0/index.pt-br.md",
"chars": 11560,
"preview": "---\ndraft: false\naliases: [\"/pt-br/\"]\n---\n\n# Conventional Commits 1.0.0\n\n## Resumo\n\nA especificação do Conventional Comm"
},
{
"path": "content/v1.0.0/index.ro.md",
"chars": 11759,
"preview": "---\ndraft: false\naliases: ['/ro/']\n---\n\n# Comiteri convenționale 1.0.0\n\n## Rezumat\n\nSpecificația Comiteri convenționale "
},
{
"path": "content/v1.0.0/index.ru.md",
"chars": 11716,
"preview": "---\ndraft: false\naliases: [\"/ru/\"]\n---\n\n# Соглашение о коммитах 1.0.0\n\n## Главное\n\nСпецификация «Соглашение о коммитах» "
},
{
"path": "content/v1.0.0/index.si.md",
"chars": 10429,
"preview": "---\ndraft: false\naliases: [\"/si/\"]\n---\n\n# සම්මුතිවාදී කමිට්ස් (Conventional Commits) 1.0.0\n\n## සාරාංශය\n\nසම්මුතිවාදී කමිට"
},
{
"path": "content/v1.0.0/index.sr.md",
"chars": 9751,
"preview": "---\ndraft: false\naliases: [\"/sr/\"]\n---\n\n# Conventional Commits 1.0.0\n\n## Summary\n\nSpecifikacija Conventional Commits pre"
},
{
"path": "content/v1.0.0/index.ta.md",
"chars": 11910,
"preview": "---\ndraft: false\naliases: [\"/ta/\"]\n---\n\n# வழக்கமான கமிட்கள் 1.0.0\n\n## Summary\n### சுருக்கம்\nவழக்கமான கமிட்கள் விவரக்குறி"
},
{
"path": "content/v1.0.0/index.th.md",
"chars": 10385,
"preview": "---\ndraft: false\naliases: [\"/th/\"]\n---\n\n# Conventional Commits 1.0.0\n\n## ข้อสรุป\n\nข้อกำหนดของ Conventional Commits คือข้"
},
{
"path": "content/v1.0.0/index.tr.md",
"chars": 10849,
"preview": "---\ndraft: false\naliases: [\"/tr/\"]\n---\n\n# Conventional Commits 1.0.0\n\n## Özet\n\nConventional Commits yönergesi, commit me"
},
{
"path": "content/v1.0.0/index.uk.md",
"chars": 9661,
"preview": "---\ndraft: false\naliases: [\"/uk/\"]\n---\n\n# Політика Комітів 1.0.0\n\n## Вступ\n\nПолітика Комітів - це полегшена угода понад"
},
{
"path": "content/v1.0.0/index.uz.md",
"chars": 12127,
"preview": "---\ndraft: false\naliases: [\"/uz/\"]\n---\n\n# Conventional Commits 1.0.0\n\n## Xulosa\n\nConventional Commits spetsifikatsiyasi "
},
{
"path": "content/v1.0.0/index.zh-hans.md",
"chars": 5923,
"preview": "---\ndraft: false\naliases: [\"/zh/\", \"/zh-hans/\"]\n---\n\n# 约定式提交 1.0.0\n\n## 概述\n\n约定式提交规范是一种基于提交信息的轻量级约定。\n它提供了一组简单规则来创建清晰的提交历史；"
},
{
"path": "content/v1.0.0/index.zh-hant.md",
"chars": 5994,
"preview": "---\ndraft: false\naliases: [\"/zh-hant/\"]\n---\n\n# 慣例式提交 Conventional Commits 1.0.0\n\n## 概述\n\n慣例式提交規範，是一種對提交說明的輕量慣例。\n它提供一些簡單的條"
},
{
"path": "content/v1.0.0-beta/index.it.md",
"chars": 7967,
"preview": "---\ndraft: false\n---\n\n# Commit Convenzionali 1.0.0-beta\n\n## Riepilogo\n\nDa maintainer di codice open source, devo poter s"
},
{
"path": "content/v1.0.0-beta/index.md",
"chars": 7601,
"preview": "---\ndraft: false\n---\n\n# Conventional Commits 1.0.0-beta\n\n## Summary\n\nAs an open-source maintainer, squash feature branch"
},
{
"path": "content/v1.0.0-beta/index.pl.md",
"chars": 8510,
"preview": "---\ndraft: false\n---\n\n# Konwencjonalne Commity 1.0.0-beta\n\n## Streszczenie\n\nJako opiekun open-sourcowego kodu, spłaszcza"
},
{
"path": "content/v1.0.0-beta/index.zh-hans.md",
"chars": 3259,
"preview": "---\ndraft: false\n---\n\n# 约定式提交 1.0.0-beta\n\n## 概述\n\n开源维护者在将特性分支合并入 `master` 时，可编写标准化的提交说明。\n\n提交说明的结构如下所示：\n\n---\n\n```\n<类型>[可选的"
},
{
"path": "content/v1.0.0-beta.1/index.it.md",
"chars": 8021,
"preview": "---\ndraft: false\n---\n\n# Commit Convenzionali 1.0.0-beta.1\n\n## Riepilogo\n\nDa maintainer di codice open source, devo poter"
},
{
"path": "content/v1.0.0-beta.1/index.md",
"chars": 7678,
"preview": "---\ndraft: false\n---\n\n# Conventional Commits 1.0.0-beta.1\n\n## Summary\n\nAs an open-source maintainer, squash feature bran"
},
{
"path": "content/v1.0.0-beta.1/index.pl.md",
"chars": 8609,
"preview": "---\ndraft: false\n---\n\n# Konwencjonalne Commity 1.0.0-beta.1\n\n## Streszczenie\n\nJako opiekun otwartych źródeł, spłaszczaj "
},
{
"path": "content/v1.0.0-beta.1/index.zh-hans.md",
"chars": 3302,
"preview": "---\ndraft: false\n---\n\n# 约定式提交 1.0.0-beta.1\n\n## 概述\n\n开源维护者在将特性分支合并入 `master` 时，可编写标准化的提交说明。\n\n提交说明的结构如下所示：\n\n---\n\n```\n<类型>[可"
},
{
"path": "content/v1.0.0-beta.2/index.es.md",
"chars": 10038,
"preview": "---\ndraft: false\n---\n\n# Commits Convencionales 1.0.0-beta.2\n\n## Resumen\n\nComo mantenedor de proyectos de código abierto,"
},
{
"path": "content/v1.0.0-beta.2/index.fr.md",
"chars": 10376,
"preview": "---\ndraft: false\naliases: [\"/fr/\"]\n---\n\n# Conventional Commits 1.0.0-beta.2\n\n## Résumé\n\nEn tant que responsable open-sou"
},
{
"path": "content/v1.0.0-beta.2/index.it.md",
"chars": 9402,
"preview": "---\ndraft: false\naliases: [\"/it/\"]\n---\n\n# Commit Convenzionali 1.0.0-beta.2\n\n## Riepilogo\n\nDa maintainer di codice open "
},
{
"path": "content/v1.0.0-beta.2/index.md",
"chars": 8862,
"preview": "---\ndraft: false\n---\n\n# Conventional Commits 1.0.0-beta.2\n\n## Summary\n\nAs an open-source maintainer, squash feature bran"
},
{
"path": "content/v1.0.0-beta.2/index.pl.md",
"chars": 9822,
"preview": "---\ndraft: false\naliases: [\"/pl/\"]\n---\n\n# Konwencjonalne Commity 1.0.0-beta.2\n\n## Streszczenie\n\nJako opiekun otwartych ź"
},
{
"path": "content/v1.0.0-beta.2/index.ru.md",
"chars": 9799,
"preview": "---\ndraft: false\naliases: [\"/ru/\"]\n---\n\n# Общепринятые Коммиты 1.0.0-beta.2\n\n## Главное\n\nКак разработчики приложений с о"
},
{
"path": "content/v1.0.0-beta.2/index.zh-hans.md",
"chars": 4339,
"preview": "---\ndraft: false\naliases: [\"/zh/\"]\n---\n\n# 约定式提交 1.0.0-beta.2\n\n## 概述\n\n开源维护者在将特性分支合并入 `master` 时，可编写标准化的提交说明。\n\n提交说明的结构如下所示"
},
{
"path": "content/v1.0.0-beta.3/index.es.md",
"chars": 9231,
"preview": "---\ndraft: false\naliases: [\"/es/\"]\n---\n\n# Convención de Commits 1.0.0-beta.3\n\n## Resumen\n\nLa especificación de Commit Co"
},
{
"path": "content/v1.0.0-beta.3/index.fr.md",
"chars": 9661,
"preview": "---\ndraft: false\naliases: [\"/fr/\"]\n---\n\n# Conventional Commits 1.0.0-beta.3\n\n## Résumé\n\nLa spécification de Conventional"
},
{
"path": "content/v1.0.0-beta.3/index.hy.md",
"chars": 9457,
"preview": "---\ndraft: false\naliases: [\"/hy/\"]\n---\n\n\n# Համաձայնեցված «Commit»֊ներ 1.0.0-beta.3\n\n## Համառոտագիր\n\nՀամաձայնեցված «commi"
},
{
"path": "content/v1.0.0-beta.3/index.it.md",
"chars": 8587,
"preview": "---\ndraft: false\naliases: [\"/it/\"]\n---\n\n# Commit Convenzionali 1.0.0-beta.3\n\n## Riepilogo\n\nLa specifica Conventional Com"
},
{
"path": "content/v1.0.0-beta.3/index.md",
"chars": 7975,
"preview": "---\ndraft: false\naliases: [\"/en/\"]\n---\n\n# Conventional Commits 1.0.0-beta.3\n\n## Summary\n\nThe Conventional Commits specif"
},
{
"path": "content/v1.0.0-beta.3/index.pt-br.md",
"chars": 9027,
"preview": "---\ndraft: false\naliases: [\"/pt-br/\"]\n---\n\n# Conventional Commits 1.0.0-beta.3\n\n## Resumo\n\nA especificação do Convention"
},
{
"path": "content/v1.0.0-beta.3/index.ru.md",
"chars": 8925,
"preview": "---\ndraft: false\naliases: [\"/ru/\"]\n---\n\n# Conventional Commits 1.0.0-beta.3\n\n## Summary\n\nConventional Commits - это прос"
},
{
"path": "content/v1.0.0-beta.3/index.zh-hans.md",
"chars": 4020,
"preview": "---\ndraft: false\naliases: [\"/zh/\", \"/zh-hans/\"]\n---\n\n# 约定式提交 1.0.0-beta.3\n\n## 概述\n\n约定式提交规范是一种基于提交消息的轻量级约定。\n它提供了一组用于创建清晰的提"
},
{
"path": "content/v1.0.0-beta.4/index.fr.md",
"chars": 10077,
"preview": "---\ndraft: false\naliases: [\"/fr/\"]\n---\n\n# Conventional Commits 1.0.0-beta.4\n\n## Résumé\n\nLa spécification de Conventional"
},
{
"path": "content/v1.0.0-beta.4/index.hy.md",
"chars": 10204,
"preview": "---\ndraft: false\naliases: [\"/hy/\"]\n---\n\n\n# Համաձայնեցված «Commit»֊ներ 1.0.0-beta.4\n\n## Համառոտագիր\n\nՀամաձայնեցված «commi"
},
{
"path": "content/v1.0.0-beta.4/index.id.md",
"chars": 9073,
"preview": "---\ndraft: false\naliases: [\"/id/\"]\n---\n\n# Conventional Commits 1.0.0-beta.4\n\n## Ringkasan\n\nConventional Commits adalah p"
},
{
"path": "content/v1.0.0-beta.4/index.it.md",
"chars": 9171,
"preview": "---\ndraft: false\naliases: [\"/it/\"]\n---\n\n# Commit Convenzionali 1.0.0-beta.4\n\n## Riepilogo\n\nLa specifica Conventional Com"
},
{
"path": "content/v1.0.0-beta.4/index.ja.md",
"chars": 5664,
"preview": "---\ndraft: false\naliases: [\"/ja/\"]\n---\n\n# Conventional Commits 1.0.0-beta.4\n\n## 概要\n\nConventional Commitsの仕様は、コミットメッセージのた"
},
{
"path": "content/v1.0.0-beta.4/index.ko.md",
"chars": 5662,
"preview": "---\ndraft: false\naliases: [\"/ko/\"]\n---\n\n# Conventional Commits 1.0.0-beta.4\n\n## 개요\n\nConventional Commits 스펙은 커밋 메시지에 곁들여"
},
{
"path": "content/v1.0.0-beta.4/index.md",
"chars": 8580,
"preview": "---\ndraft: false\naliases: [\"/en/\"]\n---\n\n# Conventional Commits 1.0.0-beta.4\n\n## Summary\n\nThe Conventional Commits specif"
},
{
"path": "content/v1.0.0-beta.4/index.pt-br.md",
"chars": 9748,
"preview": "---\ndraft: false\naliases: [\"/pt-br/\"]\n---\n\n# Conventional Commits 1.0.0-beta.4\n\n## Resumo\n\nA especificação do Convention"
},
{
"path": "content/v1.0.0-beta.4/index.ru.md",
"chars": 9615,
"preview": "---\ndraft: false\naliases: [\"/ru/\"]\n---\n\n# Conventional Commits 1.0.0-beta.4\n\n## Главное\n\nConventional Commits - это прос"
},
{
"path": "content/v1.0.0-beta.4/index.zh-hans.md",
"chars": 4316,
"preview": "---\ndraft: false\naliases: [\"/zh/\", \"/zh-hans/\"]\n---\n\n# 约定式提交 1.0.0-beta.4\n\n## 概述\n\n约定式提交规范是一种基于提交消息的轻量级约定。\n它提供了一组用于创建清晰的提"
},
{
"path": "content/v1.0.0-beta.4/index.zh-hant.md",
"chars": 4197,
"preview": "---\ndraft: false\naliases: [\"/zh-hant/\"]\n---\n\n# 慣例式提交 1.0.0-beta.4\n\n## 概述\n\n慣例式提交規範，是一種對提交說明的輕量慣例。\n它提供一些簡單的條件集合用於建立明確的提交歷史"
},
{
"path": "data/.gitkeep",
"chars": 0,
"preview": ""
},
{
"path": "docker-compose.yml",
"chars": 174,
"preview": "version: '3'\n\nservices:\n app:\n build:\n dockerfile: Dockerfile.dev\n context: .\n ports:\n - \"1313:1313"
},
{
"path": "layouts/.gitkeep",
"chars": 0,
"preview": ""
},
{
"path": "static/.gitkeep",
"chars": 0,
"preview": ""
},
{
"path": "themes/conventional-commits/.editorconfig",
"chars": 243,
"preview": "# http://editorconfig.org\n\nroot = true\n\n[*]\ncharset = utf-8\nindent_style = space\nindent_size = 2\nend_of_line = lf\ninsert"
},
{
"path": "themes/conventional-commits/.gitignore",
"chars": 1014,
"preview": ".idea\n.DS_Store\n\nstatic/css/index.css\nstatic/css/style.css\nstatic/css/style.css.map\nstatic/css/style.min.css\nstatic/js/b"
},
{
"path": "themes/conventional-commits/LICENSE",
"chars": 1081,
"preview": "The MIT License (MIT)\n\nCopyright (c) 2018 YOUR_NAME_HERE\n\nPermission is hereby granted, free of charge, to any person ob"
},
{
"path": "themes/conventional-commits/README.md",
"chars": 1656,
"preview": "# hugo conventional commits theme\nCopy hugo-conventional-commits-theme inside your my-hugo-site/theme\n\n## config.yaml ex"
},
{
"path": "themes/conventional-commits/archetypes/default.md",
"chars": 8,
"preview": "+++\n+++\n"
},
{
"path": "themes/conventional-commits/layouts/404.html",
"chars": 67,
"preview": "<!DOCTYPE html>\n<html>\n<body>\n<main>\n 404\n</main>\n</body>\n</html>\n"
},
{
"path": "themes/conventional-commits/layouts/_default/single.html",
"chars": 388,
"preview": "<!DOCTYPE html>\n<html class=\"{{ if .Site.Language.Params.rtl }}rtl{{ end }}\">\n{{- partial \"head.html\" . -}}\n<body class="
},
{
"path": "themes/conventional-commits/layouts/about/single.html",
"chars": 338,
"preview": "<!DOCTYPE html>\n<html>\n{{- partial \"head.html\" . -}}\n<body class=\"conventional-commits--loading\">\n{{- partial \"header.ht"
},
{
"path": "themes/conventional-commits/layouts/partials/footer.html",
"chars": 809,
"preview": "<footer class=\"footer\">\n <div class=\"container\">\n {{ if .Site.Params.License }}\n <div class=\"footer__license\">\n "
},
{
"path": "themes/conventional-commits/layouts/partials/head.html",
"chars": 1195,
"preview": "<head>\n <!-- Global site tag (gtag.js) - Google Analytics -->\n <script async src=\"https://www.googletagmanager.com/gta"
},
{
"path": "themes/conventional-commits/layouts/partials/header.html",
"chars": 1020,
"preview": "<header class=\"header\">\n <div class=\"container\">\n <a href=\"/\">\n <div class=\"logo\"></div>\n </a>\n <ul class"
},
{
"path": "themes/conventional-commits/layouts/partials/mini_welcome.html",
"chars": 197,
"preview": "<section class=\"welcome\">\n <div class=\"mini_container\">\n <h1 class=\"welcome__title\">{{.Param \"Title\"}}</h1>\n <p c"
},
{
"path": "themes/conventional-commits/layouts/partials/scripts.html",
"chars": 56,
"preview": "<script src=\"{{ .Site.BaseURL }}js/bundle.js\"></script>\n"
},
{
"path": "themes/conventional-commits/layouts/partials/svg-github.html",
"chars": 1915,
"preview": "<svg class=\"github\" viewBox=\"0 0 128 128\">\n <path\n fill-rule=\"evenodd\"\n clip-rule=\"evenodd\"\n d=\"M64 5.103c-33."
},
{
"path": "themes/conventional-commits/layouts/partials/welcome.html",
"chars": 560,
"preview": "<section class=\"welcome\">\n <div class=\"container\">\n <h1 class=\"welcome__title\">{{.Param \"Title\"}}</h1>\n <p class="
},
{
"path": "themes/conventional-commits/layouts/shortcodes/banner-image.html",
"chars": 129,
"preview": "<figure class=\"banner-image\">\n <img class=\"banner-image__picture\" src='{{.Get \"src\" | default \"/img/git-flow.png\"}}'>\n<"
},
{
"path": "themes/conventional-commits/package.json",
"chars": 1233,
"preview": "{\n \"name\": \"hugo-conventional-commits-theme\",\n \"version\": \"1.0.0\",\n \"description\": \"\",\n \"main\": \"index.js\",\n \"scrip"
},
{
"path": "themes/conventional-commits/static/css/scss/abstracts/_functions.scss",
"chars": 214,
"preview": "@import \"./../abstracts/variables\";\n\n\n@function get-color-accessible-for-background($color) {\n @if (lightness( $color )"
},
{
"path": "themes/conventional-commits/static/css/scss/abstracts/_mixins.scss",
"chars": 685,
"preview": "@import \"variables\";\n\n@mixin up-to-mobile {\n @media (max-width: #{$mobile-width - 1px}) {\n @content;\n }\n}\n\n\n@mixin "
},
{
"path": "themes/conventional-commits/static/css/scss/abstracts/_variables.scss",
"chars": 1079,
"preview": "$color-primary: #FE5196;\n$color-primary-light: #F77062;\n$color-neutral-light: #FFF;\n$color-neutral-dark: #000;\n\n$color-p"
},
{
"path": "themes/conventional-commits/static/css/scss/abstracts/index.scss",
"chars": 67,
"preview": "@import './variables';\n@import './mixins';\n@import './functions';\n\n"
},
{
"path": "themes/conventional-commits/static/css/scss/base/_base.scss",
"chars": 1131,
"preview": "@import \"./../abstracts/index\";\n\n* {\n margin: 0;\n padding: 0;\n box-sizing: border-box;\n -webkit-font-smoothing: anti"
},
{
"path": "themes/conventional-commits/static/css/scss/components/_banner-image.scss",
"chars": 391,
"preview": "@import \"./../abstracts/index\";\n\n.banner-image {\n width: 100%;\n border-radius: $radius-md;\n margin: $gap-lg 0;\n box-"
},
{
"path": "themes/conventional-commits/static/css/scss/components/_dropdown.scss",
"chars": 2607,
"preview": "@use \"sass:math\";\n@import \"./../abstracts/index\";\n\n@keyframes show {\n from {\n @include dropdown-animation-hidden;\n "
},
{
"path": "themes/conventional-commits/static/css/scss/layout/_footer.scss",
"chars": 517,
"preview": "@import \"./../abstracts/index\";\n\n.footer {\n margin: ($article-offset-top + ($gap-md*3)) 0 ($gap-md*3);\n\n .container {\n"
},
{
"path": "themes/conventional-commits/static/css/scss/layout/_header.scss",
"chars": 1019,
"preview": "@import \"./../abstracts/index\";\n\n.header {\n position: absolute;\n z-index: 10;\n top: 12px;\n left: 0;\n width: 100%;\n\n"
},
{
"path": "themes/conventional-commits/static/css/scss/layout/_welcome.scss",
"chars": 2182,
"preview": "@use \"sass:math\";\n@import \"./../abstracts/index\";\n\n.welcome {\n position: relative;\n z-index: 0;\n background: $color-p"
},
{
"path": "themes/conventional-commits/static/css/scss/style.scss",
"chars": 268,
"preview": "@import 'base/base';\n@import 'layout/header';\n@import 'layout/footer';\n@import 'layout/welcome';\n@import \"components/dro"
},
{
"path": "themes/conventional-commits/static/css/scss/themes/_conventional-commits.scss",
"chars": 121,
"preview": ".conventional-commits--loading {\n .dropdown__options {\n height: 0 !important;\n box-shadow: none !important;\n }\n}"
},
{
"path": "themes/conventional-commits/static/css/scss/themes/_markdown.scss",
"chars": 245,
"preview": "@import \"./../abstracts/index\";\n\nmain article.markdown-body {\n h1{\n font-size: 2.3em;\n }\n h1, h2, h3, h4, h5, h6, "
},
{
"path": "themes/conventional-commits/static/css/scss/vendors/github-markdown-css.scss",
"chars": 74,
"preview": "@import \"./../../../../node_modules/github-markdown-css/github-markdown\";\n"
},
{
"path": "themes/conventional-commits/static/js/index.js",
"chars": 815,
"preview": "import AnchorJS from 'anchor-js';\n\nclass App {\n constructor(anchors) {\n this.anchors = anchors;\n this.onInit();\n "
},
{
"path": "themes/conventional-commits/theme.toml",
"chars": 229,
"preview": "name = \"Conventional Commits\"\nlicense = \"MIT\"\ndescription = \"Hugo theme for Conventional Commits website\"\nhomepage = \"ht"
}
]
About this extraction
This page contains the full source code of the conventional-commits/conventionalcommits.org GitHub repository, extracted and formatted as plain text for AI agents and large language models (LLMs). The extraction includes 121 files (653.5 KB), approximately 203.9k tokens, and a symbol index with 7 extracted functions, classes, methods, constants, and types. Use this with OpenClaw, Claude, ChatGPT, Cursor, Windsurf, or any other AI tool that accepts text input. You can copy the full output to your clipboard or download it as a .txt file.
Extracted by GitExtract — free GitHub repo to text converter for AI. Built by Nikandr Surkov.