conventionalcommits.org/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 վերջավորությունով
```
chore!: 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
```