Слияние кода завершено, страница обновится автоматически
Спасибо, что уделили время, чтобы внести свой вклад! 
Этот проект регулируется Кодом поведения Spring. Участвуя в проекте, вы ожидаете соблюдать этот код. Пожалуйста, сообщайте о недопустимом поведении на spring-code-of-conduct@spring.io.
Если у вас есть вопрос, проверьте Stack Overflow, используя этот список тегов. Найдите существующую дискуссию или начните новую, если это необходимо.
Если вы считаете, что существует проблема, пройдитесь по существующим проблемам, пытаясь найти дискуссии, прошлые или текущие, связанные с проблемой. Чтение этих дискуссий поможет вам узнать больше о проблеме и поможет нам принять решение.#### Создайте проблему
Сообщение о проблеме или предложение новой функции — отличный способ внести вклад. Ваше мнение и разговоры, возникающие из него, обеспечивают непрерывный поток идей. Однако перед созданием тикета, пожалуйста, уделите время, чтобы задать вопросы и провести исследование.
Если вы создаете проблему после обсуждения на Stack Overflow, пожалуйста, предоставьте описание в проблеме, а не просто ссылайтесь на Stack Overflow. Трекер проблем — это важное место для записи дизайнерских обсуждений и должен быть самодостаточным.
Когда вы будете готовы, создайте проблему на GitHub. Многие проблемы вызваны незначительными особенностями поведения, опечатками и непреднамеренной конфигурацией. Создание Минимального Воспроизводимого Примера (например, начиная с https://start.spring.io) проблемы помогает команде быстро классифицировать вашу проблему и добраться до сути вопроса.#### Жизненный цикл задачи
Когда задача создается впервые, она помечается как waiting-for-triage, ожидая, пока член команды проведет ее анализ. После того как задача была рассмотрена, команда может запросить дополнительную информацию, если это необходимо, и на основе полученных данных задача либо назначается целевому релизу, либо закрывается с определенным статусом.Когда исправление готово, задача закрывается и может быть снова открыта до тех пор, пока исправление не будет выпущено. После этого задача, как правило, больше не будет перезапущена. В редких случаях, если задача не была исправлена, она может быть снова открыта. Однако в большинстве случаев любые последующие отчеты должны быть созданы как новые задачи с новым описанием.
Должны ли вы сначала создать задачу? Нет, просто создайте pull request и используйте описание для предоставления контекста и мотивации, как вы бы это сделали для задачи. Если вы хотите начать обсуждение или уже создали задачу, после создания pull request задача будет закрыта как замененная pull request, и обсуждение задачи продолжится под pull request.
Всегда проверяйте ветку main и отправляйте pull request в нее (для целевой версии см. settings.gradle). Обратная портировка в предыдущие версии будет рассматриваться по мере необходимости и отражена как версия исправления в трекере задач.
Осознанно выбирайте гранулярность ваших коммитов и объединяйте коммиты, представляющие несколько правок или исправлений одного логического изменения. См. раздел Переписывание истории в Pro Git для обзора упрощения истории коммитов.1. Все коммиты должны содержать трейлер Signed-off-by в конце каждого сообщения о коммите, чтобы указать, что вкладчик согласен с Developer Certificate of Origin. Для дополнительных деталей см. блог-пост Hello DCO, Goodbye CLA: Simplifying Contributions to Spring.1. Форматируйте сообщения о коммитах, используя 55 символов для строки заголовка, 72 символа на строку для описания, за которыми следует исправленная задача, например, Closes gh-22276. См. раздел Рекомендации по коммитам в Pro Git для лучших практик по сообщениям о коммитах, и используйте git log, чтобы увидеть примеры. Если существует предыдущая проблема, укажите номер GitHub-issues в описании pull request.
Если ваша заявка будет принята, ваш вклад может быть существенно изменен до слияния. Вы, вероятно, сохраните авторство своих Git-коммитов, при условии, что основная часть ваших изменений останется неизменной. Вас также могут попросить переработать заявку.
Если вас попросят внести исправления, просто отправьте изменения в ту же ветку, и ваш pull request будет обновлен. Другими словами, вам не нужно создавать новый pull request, когда вас просят внести изменения.
Помощь в проверке pull request — еще один отличный способ внести свой вклад. Ваше мнение может помочь сформировать реализацию новых функций. При проверке pull request, однако, воздержитесь от одобрения или отклонения PR, если вы не являетесь основным коммитером для Spring Framework.
Страницы вики Стиль кода и Настройки редактора IntelliJ IDEA определяют стандарты кодирования исходных файлов, которые мы используем, а также некоторые настройки редактора IDEA, которые мы настраиваем.
Справочная документация написана в формате Asciidoctor с использованием Antora. Исходные файлы документации находятся в директории framework-docs/modules/ROOT. Для незначительных изменений вы можете просматривать, редактировать исходные файлы и отправлять изменения напрямую с GitHub.
При внесении локальных изменений выполните ./gradlew antora и затем просмотрите результаты в framework-docs/build/site/index.html.
Asciidoctor также поддерживает живое редактирование. Для получения дополнительных сведений см. Инструменты AsciiDoc.
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )