Слияние кода завершено, страница обновится автоматически
Сначала спасибо за то, что уделяете время для внесения вклада! 
Этот проект регулируется кодом поведения Spring. Участвуя, вы обязаны соблюдать этот код. Пожалуйста, сообщите о недопустимом поведении на spring-code-of-conduct@pivotal.io.
Если у вас есть вопрос, проверьте Stack Overflow с помощью этого списка тегов. Найдите существующий диалог, или начните новый, если это необходимо.
Если вы считаете, что существует проблема, просмотрите существующие проблемы несколькими способами, чтобы найти обсуждения, прошлые или текущие, связанные с проблемой. Чтение этих обсуждений помогает вам понять проблему, и помогает нам принять решение.#### Создание проблемы
Отчет о проблеме или запрос на добавление функции — это отличный способ внести вклад. Ваши отзывы и диалоги, которые из них возникают, обеспечивают непрерывный поток идей. Однако, перед созданием тикета, пожалуйста, потратите время на обсуждение и исследование сначала.
Если вы создаете проблему после обсуждения на Stack Overflow, пожалуйста, предоставьте описание в проблеме вместо ссылки на Stack Overflow. Трекер проблем — это важное место для записи обсуждений дизайна и должен быть самодостаточным.
Как только вы будете готовы, создайте проблему на GitHub.
Когда проблема создается впервые, она помечается waiting-for-triage и ожидает, пока член команды не проверит её. Как только проблема будет проверена, команда может запросить дополнительную информацию, если это необходимо, и на основе полученных данных проблема либо получает целевую дату завершения, либо закрывается с определенным статусом. Когда исправление готово, задача закрывается и может быть снова открыта до тех пор, пока исправление не будет выпущено. После этого задача обычно больше не будет открыта. В редких случаях, если задача вообще не была исправлена, её могут снова открыть. Однако в большинстве случаев любые последующие отчёты потребуют создания новых задач с новым описанием.#### Отправка Pull Request
Если вы ещё не делали этого, пожалуйста, подпишите Соглашение о лицензии для участников. Вы будете автоматически напоминаться об этом при отправке PR.
Нужно ли создать задачу перед отправкой PR? Нет, просто создайте pull request и используйте описание для предоставления контекста и мотивации, как это делается для задачи. Если вы хотите начать обсуждение или уже создали задачу, после создания pull request задача будет закрыта как устаревшая, и обсуждение задачи продолжится под pull request.
Всегда проверяйте ветку master и отправляйте pull requests против неё (для целевой версии см. settings.gradle). Переносы исправлений на предыдущие версии будут рассматриваться в каждом случае и отражены как версия исправления в трекере задач.
Сознательно выбирайте гранулярность ваших коммитов и объединяйте коммиты, представляющие несколько правок или исправлений одного логического изменения. См. Раздел о переписывании истории в книге Pro Git для обзора упрощения истории коммитов.1. Форматируйте сообщения коммитов с использованием 55 символов для строки заголовка, 72 символов на строку для описания, за которым следует задача, которую исправили, например Closes gh-22276. См. Раздел о рекомендациях для сообщений коммитов в книге Pro Git для лучших практик по сообщениям коммитов, и используйте git log для просмотра примеров.1. Если есть предыдущая задача, укажите номер задачи GitHub в описании pull request.
Если ваш вклад будет принят, он может быть существенно изменён перед слиянием. Вы, вероятно, сохраните атрибуцию автора для ваших коммитов Git, если основная часть ваших изменений останется неизменной. Вас также могут попросить переработать вклад.
Если вас попросят внести исправления, просто отправьте изменения против той же ветки, и ваш pull request будет обновлён. Другими словами, вам не нужно создавать новый pull request, когда вас просят внести изменения.
Помощь в проверке запросов на вытягивание (pull requests) — еще один отличный способ внести свой вклад. Ваши отзывы могут помочь сформировать реализацию новых функций. Однако, если вы не являетесь основным участником проекта Spring Framework, воздержитесь от одобрения или отклонения PR.
Для получения инструкций по проверке, сборке и импорту исходного кода Spring Framework в вашу среду разработки (IDE) обратитесь к странице вики Сборка из исходного кода.
Страницы вики Стиль исходного кода и Настройки редактора IntelliJ IDEA определяют стандарты кодирования, которые мы используем, а также некоторые настройки редактора IDEA.### Справочная документация
Справочная документация находится в директории src/docs/asciidoc в формате Asciidoctor. Для незначительных изменений вы можете просматривать, редактировать исходные файлы и отправлять изменения напрямую с GitHub.
При выполнении изменений локально выполните команду ./gradlew asciidoctor, а затем просмотрите результат под директорией build/asciidoc/html5/index.html.
Asciidoctor также поддерживает живое редактирование. Для получения дополнительной информации прочитайте Редактирование AsciiDoc с живым предварительным просмотром. Обратите внимание, что если вы выберете опцию Системный монитор, вы найдете файл Guardfile в директории src/docs/asciidoc.
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )