Слияние кода завершено, страница обновится автоматически
В этом документе собраны наиболее важные моменты для людей, заинтересованных в участии в разработке Godot, особенно через отчёты об ошибках или пул реквесты.
Документация Godot содержит специальный раздел «Участие» (https://docs.godotengine.org/en/latest/contributing/ways_to_contribute.html), в котором подробно описаны эти и другие моменты, и рекомендуется к прочтению.
Сообщайте об ошибках здесь (https://github.com/godotengine/godot/issues/new?assignees=&labels=&template=bug_report.yml). Пожалуйста, следуйте инструкциям в шаблоне при выполнении.
Обратите внимание, пожалуйста, включите Минимальный проект воспроизведения (MRP), который представляет собой небольшой проект Godot, воспроизводящий проблему, без лишних файлов.
Убедитесь, что папка .godot не включена в архив, чтобы сэкономить место.
Убедитесь, что ошибка, с которой вы столкнулись, воспроизводима в последних версиях Godot. Вы можете найти обзор всех релизов Godot на веб-сайте (https://godotengine.org/download/archive/), чтобы подтвердить, является ли ваша текущая версия последней. Стоит протестировать как последнюю стабильную версию, так и последний снимок разработчика для следующего выпуска Godot.
Если вы сталкиваетесь с ошибкой, которой не было в более ранней версии Godot (что мы называем регрессией), пожалуйста, упомяните об этом и уточните, какие версии вы тестировали (как работающие, так и демонстрирующие ошибку).
Основной трекер проблем предназначен для отчётов об ошибках и не принимает предложения о функциях.
Вместо этого перейдите в репозиторий предложений Godot (https://github.com/godotengine/godot-proposals) и следуйте инструкциям в файле README и шаблоне проблемы.
Если вы хотите добавить новые функции движка, убедитесь, что:
Аналогичные правила могут применяться при внесении исправлений ошибок — всегда лучше сначала обсудить реализацию в отчёте об ошибке, если вы не уверены на 100%, каким будет лучшее исправление.
Вы можете обратиться к процессу проверки пул реквеста (https://docs.godotengine.org/en/latest/contributing/workflow/pr_review_guidelines.html) для понимания предполагаемого жизненного цикла пул реквестов. Это должно помочь вам убедиться, что ваш пул реквест соответствует требованиям.
Помимо следующих советов, также ознакомьтесь с руководством по разработке движка (https://docs.godotengine.org/en/latest/contributing/development/index.html) для ознакомления с разработкой на Godot.
Документы о вкладе (https://docs.godotengine.org/en/latest/contributing/ways_to_contribute.html) также содержат важную информацию о рабочем процессе PR (с полезным руководством по использованию Git) и наших рекомендациях по стилю кода (https://docs.godotengine.org/en/latest/contributing/development/code_style_guidelines.html), которым должны следовать все вклады.
Старайтесь делать простые PR, которые обрабатывают одну конкретную тему. Как и при сообщении о проблемах, лучше открыть 3 разных PR, каждый из которых касается отдельной проблемы, чем один большой PR с тремя коммитами. Это упрощает проверку, утверждение и объединение изменений независимо друг от друга.
При обновлении вашего форка с изменениями вверх по течению, пожалуйста, используйте git pull --rebase, чтобы избежать создания «коммитов слияния». Эти коммиты излишне загрязняют историю git при поступлении от PR. Также старайтесь делать коммиты, которые переводят движок из одного стабильного состояния в другое. То есть, если в вашем первом коммите была ошибка, которую вы исправили во втором коммите, попробуйте объединить их перед созданием pull request. Это включает исправление проблем со сборкой или опечаток, добавление документации и т. д.
См. нашу документацию PR workflow для получения советов по использованию Git, изменению коммитов и перебазированию веток.
Этот Git style guide также содержит некоторые полезные рекомендации.
Способ форматирования сообщений о коммитах очень важен для обеспечения того, чтобы история коммитов и журнал изменений были легко читаемыми и понятными. Сообщение о коммите Git форматируется как короткий заголовок (первая строка) и расширенное описание (всё после первой строки и пустой разделительной линии).
Короткая строка заголовка — самая важная часть, так как она будет отображаться в журнале изменений или в интерфейсе GitHub, если вы не нажмёте кнопку «развернуть». Старайтесь, чтобы эта первая строка была не более 72 символов, но при необходимости можно немного превысить это значение, чтобы предложение было понятным.
Оно должно быть написано на английском языке, начинаться с заглавной буквы и обычно с глагола в повелительном наклонении. Типичное исправление ошибки начинается с «Fix», а добавление новой функции — с «Add». Можно добавить префикс, чтобы указать область движка, на которую влияет коммит. Вот несколько примеров:
Object::has_method() for script static methods.Если ваш коммит исправляет зарегистрированную проблему, пожалуйста, включите её в описание PR (не в заголовок или сообщение о коммите), используя одно из ключевых слов закрытия GitHub, например «Fixes #1234». Это приведёт к автоматическому закрытию проблемы, если PR будет объединён. Добавить его в сообщение о коммите проще, но это добавляет много ненужных обновлений в проблему, отвлекая от темы.
Вот пример хорошо отформатированного сообщения о коммите (обратите внимание, что расширенное описание также вручную перенесено на 80 символов для удобства чтения):
Prevent French fries carbonization by fixing heat regulation
When using the French fries frying module, Godot would not regulate the heat
and thus bring the oil bath to supercritical liquid conditions, thus causing
unwanted side effects in the physics engine.
By fixing the regulation system via an added binding to the internal feature,
this commit now ensures that Godot will not go past the ebullition temperature
of cooking oil under normal atmospheric conditions.
Примечание: При использовании онлайн-редактора GitHub или его функции перетаскивания пожалуйста отредактируйте заголовок коммита на что-то значимое. Коммиты с названием «Update my_file.cpp» не будут приняты.
Если ваш pull request добавляет методы, свойства или сигналы, которые доступны для API сценариев, вы должны обновить ссылку на класс, чтобы задокументировать их. Это необходимо для того, чтобы покрытие документации не уменьшалось по мере объединения вкладов.
Обновите файлы документации XML, используя свой скомпилированный двоичный файл, затем заполните описания. Следуйте руководству по стилю, описанному в Руководстве по написанию документации.
Если ваш запрос на вытягивание изменяет части кода неочевидным образом, обязательно добавьте комментарии в код. Это помогает другим людям понять изменение без необходимости углубляться в историю Git.
При исправлении ошибки или добавлении новой функции мы рекомендуем включать модульные тесты в тот же коммит, что и остальная часть запроса на вытягивание. Модульные тесты — это фрагменты кода, которые сравнивают Вывод к заранее определённому ожидаемому результату для обнаружения регрессий.
Тесты компилируются и запускаются в GitHub Actions для каждого коммита и пул-реквеста.
Пул-реквесты, включающие тесты, с большей вероятностью будут объединены, поскольку мы можем быть более уверены в том, что они не станут целью регрессии в будущем.
Для ошибок модульные тесты должны охватывать функциональность, которая ранее была нарушена. Если всё сделано правильно, это гарантирует, что регрессии больше не появятся в будущем. Для новых функций модульные тесты должны покрывать вновь добавленную функциональность, тестируя как случаи «успеха», так и «ожидаемого сбоя», если применимо.
Не стесняйтесь вносить самостоятельные пул-реквесты для добавления новых тестов или улучшения существующих.
См. Модульное тестирование для получения информации о написании тестов в кодовой базе C++ Godot.
Вклад в переводы Godot
Вы можете внести свой вклад в переводы Godot на Hosted Weblate, открытой веб-платформе для перевода.
Пожалуйста, обратитесь к нашим руководящим принципам локализации редактора и документации, чтобы получить обзор переводческих ресурсов и того, чему они соответствуют.
Общение с разработчиками
Сообщество Godot Engine имеет много каналов связи, некоторые из которых используются больше для обсуждений на уровне пользователей и поддержки, другие — больше для обсуждения разработки.
Чтобы общаться с разработчиками (например, чтобы обсудить функцию, которую вы хотите реализовать, или ошибку, которую хотите исправить), можно использовать следующие каналы:
— Чат участников Godot: там вы найдёте большинство основных разработчиков, поэтому это основная платформа для прямого общения о разработке Godot Engine. Просмотрите Справочник, чтобы ознакомиться с общедоступными каналами, ориентированными на различные области движка, которые могут вас заинтересовать.
— Система отслеживания ошибок: если есть существующая проблема, которую вы хотите обсудить, вы можете принять непосредственное участие. Если нет, вы можете открыть новый вопрос. Пожалуйста, соблюдайте изложенные выше рекомендации по сообщению об ошибках.
— Предложения по функциям: для предложения новой функции у нас есть специальный трекер проблем. Не стесняйтесь сначала поговорить о своей идее в чате участников Godot, чтобы убедиться, что она имеет смысл в контексте Godot.
Спасибо за ваш интерес к сотрудничеству!
— Команда разработчиков Godot
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )