Слияние кода завершено, страница обновится автоматически
Если вы нашли баг, мы хотели бы об этом узнать. В настоящее время мы также принимаем запросы на новые функции, но перед тем как отправить их через Github Issues, пожалуйста, убедитесь, что:
Если вам не удалось найти открытый вопрос, связанный с проблемой, или любой вопрос (как закрытый, так и открытый) о запросе на функцию, вы можете открыть новый. Обязательно укажите заголовок и чёткое описание, включая как можно больше релевантной информации, а при отправке отчёта об ошибке желательно предоставить пример кода или исполняемый тестовый случай, демонстрирующий ожидаемое поведение, которое не происходит.
Отправьте GitHub Pull Request на Fuel с чётким списком того, что вы сделали (подробнее о pull requests).
В вашем Pull Request обязательно укажите заголовок и ясное описание того, что он добавляет, удаляет или изменяет. Приведённые ниже рекомендации по оформлению сообщений коммитов могут быть применены к Pull Request в целом.
Всегда пишите понятное сообщение журнала для своих коммитов. Thoughtbot написал отличную статью о лучших сообщениях коммитов, и следующее взято и адаптировано из этой статьи:
Другие разработчики, особенно вы-через-две-недели и вы-из-следующего-года, будут благодарны вам за вашу предусмотрительность и многословность, когда они запустят git blame, чтобы увидеть, почему там есть это условие.
Первая строка всегда должна быть 50 символов или меньше, и за ней должна следовать пустая строка. Многие IDE и редакторы поставляются с плагинами синтаксиса, отступа и типа файла для Git-коммитов, которые могут помочь здесь.
Ответьте на следующие вопросы:
Почему это изменение необходимо? Этот вопрос сообщает рецензентам вашего pull request, чего ожидать от коммита, позволяя им легче определить и указать на несвязанные изменения.
Как оно решает проблему? Опишите на высоком уровне, что было сделано для внесения изменений. «Внедрить красно-чёрное дерево для увеличения скорости поиска» или «Удалить <проблемную зависимость X>, которая вызывала <конкретное описание проблемы, вызванной зависимостью>» — хорошие примеры. Если ваше изменение очевидно, вы можете опустить ответ на этот вопрос.
Какие побочные эффекты у этого изменения? Это самый важный вопрос для ответа, поскольку он может указывать на проблемы, когда вы вносите слишком много изменений в один коммит или ветку. Один или два пункта списка для связанных изменений могут быть приемлемыми, но пять или шесть, вероятно, являются индикаторами коммита, который делает слишком много вещей.
Fuel использует ktlint для устранения ошибок стиля. Это гарантирует, что наш проект имеет согласованность в стилях и/или форматировании.
Чтобы убедиться, что у вас есть быстрый цикл обратной связи по ошибкам стиля, рассмотрите возможность установки ktlint локально и интеграции его в качестве хука фиксации github.
curl -sSLO https://github.com/shyiko/ktlint/releases/download/0.29.0/ktlint &&
chmod a+x ktlint &&
sudo mv ktlint /usr/local/bin/
ktlint --install-git-pre-commit-hook
Кроме того, если вы предпочитаете форматировать код в своём редакторе, вы можете использовать файл .editorconfig, предоставленный ktlint. .editorconfig хорошо работает со многими редакторами (читайте подробнее).
Вы можете взять копию... Редактор конфигурации редактора .editorconfig можно скачать, выполнив следующую команду в корне проекта:
$ curl -O https://raw.githubusercontent.com/shyiko/ktlint/master/.editorconfig
Для получения более подробных инструкций посетите репозиторий ktlint.
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )