Слияние кода завершено, страница обновится автоматически
Разработка и тестирование программного обеспечения: рекомендации по работе с кодовой базой
К сожалению, мы не можем исследовать или исправлять ошибки без минимального воспроизведения, поэтому, если мы не получим от вас ответ, мы закроем вашу проблему, которой недостаточно информации для воспроизведения.
Вы можете создавать новые проблемы, заполнив нашу форму новой проблемы.
Прежде чем отправить запрос на включение (Pull Request, PR), рассмотрите следующие рекомендации:
git checkout -b my-fix-branch master
git commit -a
Примечание: необязательная опция командной строки -a автоматически «добавит» и «удалит» отредактированные файлы.
git push origin my-fix-branch
ant-design-blazor:master.git rebase master -i
git push -f
Вот и всё! Спасибо за ваш вклад!
После объединения вашего запроса на включение вы можете безопасно удалить свою ветку и извлечь изменения из основного (восходящего) репозитория:
git push origin --delete my-fix-branch
git checkout master -f
git branch -D my-fix-branch
git pull --ff upstream master
Чтобы обеспечить согласованность исходного кода, помните об этих правилах при работе:
У нас есть очень точные правила относительно того, как можно форматировать наши сообщения git commit. Это приводит к более читаемым сообщениям, которые легко отслеживать при просмотре истории проекта. Между тем, мы используем сообщения git commit для создания журнала изменений ant-design-blazor.
Каждое сообщение фиксации состоит из заголовка, тела и нижнего колонтитула. Заголовок имеет специальный формат, включающий тип, область действия и тему:
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
Заголовок является обязательным, а область действия заголовка — необязательной.
Любая строка сообщения фиксации не может быть длиннее 100 символов! Это позволяет легче читать сообщение на GitHub, а также в различных инструментах git.
Нижний колонтитул также должен содержать ссылку на закрытую проблему, если таковая имеется.
Примеры: (ещё больше примеров)
docs(changelog): update change log to beta.5
fix(release): need to depend on latest rxjs and zone.js
The version in our package.json gets copied to the one we publish, and users need **Формат сообщения о фиксации изменений**
Последние из них.
**Откат**
Если фиксация отменяет предыдущую фиксацию, она должна начинаться с revert: , за которым следует заголовок отменённой фиксации. В теле должно быть сказано: «Это отменяет фиксацию <хэш>», где хэш — это SHA фиксации, которая отменяется.
**Тип**
Должен быть одним из следующих:
* **build**: изменения, которые влияют на систему сборки или внешние зависимости (примеры областей: gulp, broccoli, npm);
* **ci**: изменения в нашей конфигурации CI и сценариях (примеры областей: Travis, Circle, BrowserStack, SauceLabs);
* **docs**: только изменения документации;
* **feat**: новая функция;
* **fix**: исправление ошибки;
* **perf**: изменение кода, которое улучшает производительность;
* **refactor**: изменение кода, которое не исправляет ошибку и не добавляет функцию;
* **style**: изменения, которые не влияют на смысл кода (пробел, форматирование, отсутствие точек с запятой и т. д.);
* **test**: добавление недостающих тестов или исправление существующих тестов.
**Область**
Область должна быть именем модуля, который затрагивается (имя папки или другие значимые слова), и должна иметь префикс *module:* (как воспринимается человеком, читающим журнал изменений, созданный из сообщений фиксации).
Вот несколько примеров:
* module:alert;
* module:badge;
* module:breadcrumb;
* module:OTHER_COMPONENT_NAME.
В настоящее время существует несколько исключений из правила «использовать имя модуля»:
* **packaging**: используется для изменений, которые изменяют макет пакета npm, например, изменения общедоступного пути, изменения package.json, изменения формата файла d.ts, изменения пакетов и т.д.;
* **changelog**: используется для обновления примечаний к выпуску в CHANGELOG.md;
* **showcase**: используется для связанных с docs-app (ng.ant.design) изменений в каталоге showcase / репозитория;
* none/пустая строка: полезна для style, test и refactor изменений, которые выполняются во всех пакетах (например, style: добавить отсутствующие точки с запятой).
**Тема**
Тема содержит краткое описание изменения:
* используйте повелительное наклонение, настоящее время: «изменить», а не «изменено» или «изменения»;
* не используйте заглавную букву;
* нет точки (.) в конце.
**Тело**
Как и в **теме**, используйте повелительное наклонение, настоящее время: «измените», а не «изменённое» или «изменение».
Тело должно включать мотивацию для изменения и противопоставлять его предыдущему поведению.
**Нижний колонтитул**
Нижний колонтитул должен содержать любую информацию о **критических изменениях** и также является местом для ссылки на проблемы GitHub, которые эта фиксация **закрывает**.
**Критические изменения** должны начинаться со слов BREAKING CHANGE: с пробелом или двумя новыми строками. Остальная часть сообщения фиксации затем используется для этого.
Подробное объяснение можно найти в этом [документе][commit-message-format].
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )