From 51d26a16b69c74b4b10de065f4f7f59106056379 Mon Sep 17 00:00:00 2001 From: Pavel Puchkov <0x6368656174@gmail.com> Date: Sun, 28 Oct 2018 22:46:42 +1000 Subject: [PATCH] feat: Russian translation added * feat: Russian translation added * fix: fix Russian translation and add it to config.yaml * fix: Russian commit structure * fix: move russian translate to content/v1.0.0-beta.2 --- config.yaml | 15 +++ content/v1.0.0-beta.2/index.ru.md | 210 ++++++++++++++++++++++++++++++ 2 files changed, 225 insertions(+) create mode 100644 content/v1.0.0-beta.2/index.ru.md diff --git a/config.yaml b/config.yaml index 655b3d3..3fc114f 100644 --- a/config.yaml +++ b/config.yaml @@ -100,3 +100,18 @@ languages: current: v1.0.0-beta.2 list: - v1.0.0-beta.2 + + ru: + weight: 2 + languageName: "Русский" + title: Общепринятые коммиты + description: Спецификация о добавлении сообщений коммитов, которые удобны для чтения людьми и машинами + actions: + - label: Читать спецификацию + url: '#спецификация' + - label: GitHub + url: 'https://github.com/conventional-commits/conventionalcommits.org' + versions: + current: v1.0.0-beta.2 + list: + - v1.0.0-beta.2 diff --git a/content/v1.0.0-beta.2/index.ru.md b/content/v1.0.0-beta.2/index.ru.md new file mode 100644 index 0000000..89663bc --- /dev/null +++ b/content/v1.0.0-beta.2/index.ru.md @@ -0,0 +1,210 @@ +--- +draft: false +aliases: ["/ru/"] +--- + +# Общепринятые Коммиты 1.0.0-beta.2 + +## Главное + +Как разработчики приложений с открытым исходным кодом, использующие слияние (squash) git'а в ветку `master` должны писать +общепринятые сообщения коммитов. + +Сообщения коммитов должны иметь следующую структуру: + +--- + +``` +[optional область]: <краткое описание> + +[optional тело] + +[optional подвал] +``` +--- + +
+Коммиты включают следующие элементы, чтоб сообщить пользователям вашей библиотеки, что ни в себе содержат: + +1. **fix:** - коммит _типа_ `fix`, который исправляет баги в вашем коде (он соотносится с [`PATCH`](http://semver.org/#summary) + в правилах семантического управления версиями). +1. **feat:** - коммит _type_ `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/marionebl/commitlint/tree/master/%40commitlint/config-conventional) + (основанный на [the Angular convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) + рекомендует `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:` и другие. + Мы так же рекомендуем `improvement` для коммитов, которые улучшают текущую реализацию без добавления новой функциональности + или исправления ошибок. Обратите внимание, что данный тип коммитов не управляется данной спецификацией и не + имеет никакого соотношения в правилах семантического управления версиями (за исключением случае, если он не содержит в + себе BREAKING CHANGE). +
+Область (scope) может быть определена для любого типа коммита, чтоб описать контекст коммита. Она содержится в круглых +скобках, например, `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 +``` + +### Коммит без тела +``` +docs: correct spelling of CHANGELOG +``` + +### Коммит с указанной областью (scope) +``` +feat(lang): added polish language +``` + +### Коммит, исправляющий баги и содержащий (необязательный) номер в баг-трекере (issue) в подвале +``` +fix: minor typos in code + +see the issue for details on the typos fixed + +fixes issue #12 +``` + +## Вступление +В разработке программного обеспечения я заметил, что ошибки чаще всего распространяются между приложениями. +Модульное тестирование отлично подходит для тестирования взаимодействий, о которых знает разработчик с открытым исходным +кодом, но не затрагивает интересов тех, то использует вашу библиотеку. + +Любой, кто обновился до новой версии патча зависимостей, только для того, чтобы увидеть, как его приложение начинает +вываливаться с 500 ошибкой, знает, насколько важна хорошая читаемая история изменений приложения +(и [в идеале хорошо сохранившийся CHANGELOG](http://keepachangelog.com/en/0.3.0/)). + +Общепринятые Коммиты - это простое соглашение для написания сообщений коммитов. Оно определяет простой +набор правил для создания точной истории коммитов, а так же упрощает написание автоматических утилит поверх истории коммитов. +Данное соглашение совместимо с правилами семантического управления версиями [SemVer](http://semver.org), описывая +правила добавления новой функциональности, исправления багов и описания нарушения обратной совместимости в сообщениях коммитов. + +Внедряя это соглашение, мы создаем общий язык, который упрощает отладку между проектами. + +## Спецификация + +Слова “ДОЛЖЕН”, “ДОЛЖНО”, “ДОЛЖНЫ” (“MUST”, “SHOULD”, “SHALL”), “МОГУТ”, “МОЖЕТ” (“MAY”) и “НЕ ОБЯЗАТЕЛЬНАЯ” (“OPTIONAL”) +в этом документе должны интерпретироваться как описано в [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt). + +1. Коммиты ДОЛЖНЫ начинаться с префикса, который содержит существительное `feat`, `fix` и др., за которым следует + двоеточие и пробел. +1. Тип `feat` ДОЛЖЕН использоваться для коммитов, которые добавляют новую функциональность в ваше приложение или библиотеку. +1. Тип `fix` ДОЛЖЕН использоваться для коммитов, которые исправляют баги в вашем приложении или библиотеки. +1. НЕ ОБЯЗАТЕЛЬНАЯ область (scope) МОЖЕТ быть указана после типа. Область - это фраза, описывающая контекст кодовой + базы, измененной коммитом, заключенная в круглые скобки. Например, `fix(parser):`. +1. Краткое описания ДОЛЖНО следовать сразу же после указания префикса типа/области. Краткое описание - это сжатое описание изменения + кода, которое несет в себе коммит, например, `fix: array parsing issue when multiple spaces were contained in string.` +1. Тело коммита содержит в себе дополнительное, полное описание о изменении кодовой базы. Оно МОЖЕТ следовать после краткого описания. + Тело ДОЛЖНО идти после краткого описания, через одну пустую строку. +1. Подвал МОЖЕТ идти после тела коммита через одну пустую строку. Подвал ДОЛЖЕН содержать дополнительную ссылку на + запись в баг-трекере (issue) об изменениях в кодовой базы (т.е. issue, которое он исправляет, например `Fixes #13`). +1. Нарушения обратной совместимости ДОЛЖНЫ содержаться в самом начале тела или подвала коммита. Нарушения обратной совместимости + ДОЛЖНЫ начинаться с текста в верхнем регистре `BREAKING CHANGE`, за которым следует двоеточие и пробел. +1. Описание нарушения обратной совместимости ДОЛЖНО следовать сразу же после `BREAKING CHANGE: `. Оно должно разъяснять, + что изменилось в API. Например, `BREAKING CHANGE: environment variables now take precedence over config files.` +1. Подвал ДОЛЖЕН содержать только `BREAKING CHANGE`, внешние ссылки, ссылки на номера задач в баг-трекере (issue), и + другую мета-информацию. +1. Типы отличные от `feat` и `fix` МОГУТ использоваться в сообщениях коммитов. + +## Почему нужно использовать Общепринятые Коммиты + +* Автоматически создаваемые CHANGELOG'и. +* Автоматически определяемая семантическая версия приложения или библиотеки (основываясь на типах коммитов). +* Коммуникация о характере изменения между товарищами по команде, общественностью и другими заинтересованными сторонами. +* Автоматически срабатываемый процесс сборки и публикации. +* Людям проще участвовать в вашем проекте, потому что им доступна более структурированная история коммитов. + +## FAQ + +### Как я должен писать сообщения коммитов на начальной стадии разработки? + +Мы рекомендуем писать сообщения коммитов так, как будто вы уже выпустили продукт. Как правило, *кто-то*, например, +ваши коллеги, уже используют ваш код. И они хотят знать, что исправилось, что изменилось, какие нарушения обратной +совместимости появились и т.д. + +### В каком регистре я должен писать заголовки коммитов? + +Любой регистр можно использовать, но лучше во всей истории использовать один стиль. + +### Что мне делать, если коммит должен содержать больше одного типа? + +Вернитесь назад и сделайте несколько коммитов, если это возможно. Часть из преимуществ использования Общепринятых Коммитов +- это его способность побуждать делать более организованные коммиты и PR'ы. + +### Разве это не препятствует быстрому развитию и быстрой интеграции? + +Это препятствует быстрому развитию в неорганизованном виде. Это помогает быстро двигаться в нескольких проектах +с несколькими участниками. + +### Могут ли Общепринятые Коммиты заставить разработчиков ограничивать их типы коммитов, потому что им придется думать об этих типах? + +Общепринятые Коммиты побуждают делать больше коммитов с определенными типами, такими как `fix`. Кроме того, гибкость +Общепринятые Коммиты позволяют вашей команде создавать свои собственные типы и изменять их с течением времени. + +### Как она связывается с правилами семантического управления версиями [SemVer](http://semver.org)? + +`fix` тип коммита должен быть отражен в `PATCH`-релизе. `feat` тип коммита должен быть отражен в `MINOR`-релизе. +Коммиты с `BREAKING CHANGE` в теле или подвале, не зависимо от типа, должны быть отражены в `MAJOR`-релизе. + +### Как я должен версионировать мои расширения к спецификации Общепринятых Коммитов, например, `@jameswomack/conventional-commit-spec`? + +Мы рекомендуем использовать [SemVer](http://semver.org) для релизов ваших расширений к этой спецификации (и рекомендуем делать эти расширения!). + +### Что мне делать, если я случайно использовал не тот тип коммита? + +#### Что если вы использовали тип, который имеет спецификацию, но это неправильный тип. Например, `fix` вместо `feat` + +Перед слиянием или релизом ошибки, мы рекомендуем использовать `git rebase -i` для редактирования истории коммитов. После +`release`, исправления будут отличаться в зависимости от того, какие инструменты вы используете. + +#### Когда вы использовали тип, *не* описанный спецификацией, например, `feet` вместо `feat` + +Это не конец света, это просто обозначает, что коммит будет упущен при работе утилит, основанных на спецификации. + +### Должны ли все мои соавторы использовать спецификацию Conventional Commit? + +Нет! Если ваш рабочий процесс основа на использовании слияния (squash) Git, сопровождающий проекта может отчистить +историю всех предыдущих коммитов при их слияния, не добавляя рабочей нагрузки на случайные коммиты. Обычно, +рабочий процесс строится на том, что ваша система Git автоматически объединяет (squash) все предыдущие коммиты пред +перед pull-запросом и предоставляет форму сопровождающему проекта для ввода нового коммита. + +## О спецификации + +Общепринятые Коммиты вдохновлены и основаны на +[Angular Commit Guidelines](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines). + +Первый черновик спецификации был написан в сотрудничестве с некоторыми участниками: + +* [conventional-changelog](https://github.com/conventional-changelog/conventional-changelog): набор утилит для парсинга + стандартных сообщений коммитов из истории git. +* [bumped](https://bumped.github.io): утилита для релиза приложений, которая позволяет легко выполнять действия + до и после релиза новой версии ваших приложений. +* [unleash](https://github.com/netflix/unleash): утилита для автоматического релиза и публикации приложений. +* [lerna](https://github.com/lerna/lerna): утилита для управления моно-репозиториями, которая выросла и проекта Babel. + +## Проекты, использующие Общепринятые Коммиты + +* [yargs](https://github.com/yargs/yargs): всеми любимый парсер параметров командной строки. +* [istanbuljs](https://github.com/istanbuljs/istanbuljs): коллекция утилит и библиотек с открытым исходным кодом для оценки покрытия + тестами вашего кода. +* [standard-version](https://github.com/conventional-changelog/standard-version): автоматический менеджер версий + и CHANGELOG'ов, использующий GitHub `new squash` кнопку, который рекомендует использовать Общепринятые Коммиты. +* [uPortal-home](https://github.com/UW-Madison-DoIT/angularjs-portal) и [uPortal-application-framework](https://github.com/UW-Madison-DoIT/uw-frame): + новый дополнительный пользовательский интерфейс [Apereo uPortal](https://www.apereo.org/projects/uportal). +* [massive.js](https://github.com/dmfay/massive-js): библиотека для доступа к данным PostrgeSQL для Node. +* [electron](https://github.com/electron/electron): утилита для создания крос-платформенных приложений на JavaScript, HTM и CSS. +* [scroll-utility](https://github.com/LeDDGroup/scroll-utility): простая в использовании утилита контроля прокрутки центральных + элементов и плавной анимации. + +[![Общепринятые Коммиты](https://img.shields.io/badge/Conventional%20Commits-1.0.0-yellow.svg)](https://conventionalcommits.org) + +_Хотите, чтоб ваш проект появился в этом списке?_ [Отправьте Pull Request](https://github.com/conventional-changelog/conventionalcommits.org/pulls).