Слияние кода завершено, страница обновится автоматически
Хотите внести свой вклад в проект GLC? Отлично! Эта страница содержит информацию об отчётах о проблемах, а также некоторые советы и рекомендации, полезные для опытных участников проектов с открытым исходным кодом. Наконец, перед тем как начать участвовать, обязательно прочитайте наши правила сообщества.
Разработчики GLC серьёзно относятся к безопасности. Если вы обнаружите проблему безопасности, пожалуйста, немедленно сообщите им об этом!
Пожалуйста, НЕ создавайте публичный отчёт, вместо этого отправьте свой отчёт конфиденциально на xuri.me.
Отчёты о безопасности очень ценятся, и мы публично поблагодарим вас за них. В настоящее время мы не предлагаем программу вознаграждений за обнаружение проблем безопасности, но не исключаем её в будущем.
Отличный способ внести свой вклад в проект — отправить подробный отчёт при возникновении проблемы. Мы всегда ценим хорошо написанные, подробные отчёты об ошибках и будем благодарны вам за это!
Проверьте, что наша база данных проблем уже не включает эту проблему или предложение, прежде чем создавать новую проблему. Если вы найдёте совпадение, вы можете использовать кнопку «Подписаться», чтобы получать уведомления об обновлениях. Не оставляйте случайные комментарии «+1» или «У меня тоже есть эта проблема», так как они только засоряют обсуждение и не помогают решить проблему. Однако, если у вас есть способы воспроизвести проблему или дополнительная информация, которая может помочь решить проблему, оставьте комментарий.
При сообщении о проблемах всегда включайте вывод команды go env.
Также включите шаги, необходимые для воспроизведения проблемы, если это возможно и применимо. Эта информация поможет нам быстрее рассмотреть и исправить вашу проблему. При отправке длинных файлов журналов рассмотрите возможность публикации их в виде гиста https://gist.github.com. Не забудьте удалить конфиденциальные данные из ваших файлов журналов перед публикацией (вы можете заменить эти части на «ОТРЕДАКТИРОВАНО»).
В этом разделе даются краткие советы и рекомендации опытным участникам.
Не уверены, стоит ли отправлять запрос на исправление опечатки? Нашли ошибку и знаете, как её исправить? Сделайте это! Мы будем признательны. Любое значительное улучшение должно быть задокументировано как проблема GitHub, прежде чем кто-либо начнёт над ней работать.
Мы всегда рады получать запросы на вытягивание. Мы делаем всё возможное, чтобы обработать их быстро. Если ваш запрос на вытягивание не будет принят с первой попытки, не расстраивайтесь!
Вы можете предложить новые дизайны существующих функций GLC. Вы также можете разработать совершенно новые функции. Мы действительно ценим участников, которые хотят реорганизовать или иным образом очистить наш проект.
Мы стараемся поддерживать GLC компактным и целенаправленным. GLC не может делать всё для всех. Это означает, что мы можем отказаться от включения новой функции. Однако может быть способ реализовать эту функцию поверх GLC.
Форкните репозиторий и внесите изменения в своём форке в функциональной ветке:
Проведите модульные тесты для своих изменений. Go имеет отличную встроенную среду тестирования; используйте её! Взгляните на существующие тесты для вдохновения. Запустите полный тест в своей ветке перед отправкой запроса на вытягивание.
Обновляйте документацию при создании или изменении функций. Проверьте свои изменения документации на ясность, лаконичность и правильность, а также на чистоту сборки документации.
Пишите чистый код. Универсально отформатированный код способствует лёгкости написания, чтения и обслуживания. Всегда запускайте gofmt -s -w file.go для каждого файла. Изменён файл перед фиксацией изменений. Большинство редакторов имеют плагины, которые делают это автоматически.
Описания запросов на включение (pull request) должны быть как можно более понятными и включать ссылку на все проблемы, которые они решают.
Прежде чем вносить большие или важные изменения, постарайтесь скоординироваться с сопровождающими проекта перед отправкой запроса на включение. Это избавит вас от лишней работы, которая может быть не объединена.
Большие запросы на включение, отправленные без предварительного общения, вряд ли будут успешными.
Хотя запросы на включение являются методологией для отправки изменений в код, изменения с большей вероятностью будут приняты, если они сопровождаются дополнительной инженерной работой. Хотя мы не определяем это явно, большинство из этих целей достигаются через общение о целях дизайна и последующих решениях. Часто помогает сначала сформулировать проблему, прежде чем предлагать решения.
Как правило, лучшие способы сделать это — отправить задачу, указав проблему. Эта задача может включать формулировку проблемы и контрольный список с требованиями. Если предлагаются решения, следует перечислить альтернативы и исключить их. Даже если критерии исключения решения незначительны, так и скажите.
Более крупные изменения обычно лучше работают с проектными документами. Они сосредоточены на предоставлении контекста дизайну во время разработки функции и могут информировать будущие вклады в документацию.
Сообщения о фиксации должны начинаться с заглавной буквы и краткого резюме, написанного в повелительном наклонении, за которым следует необязательный, более подробный пояснительный текст, отделённый от резюме пустой строкой.
В сообщениях о фиксации следует придерживаться лучших практик, включая объяснение контекста проблемы и того, как она была решена, включая предостережения или последующие необходимые изменения. Они должны рассказывать историю изменения и давать читателям понимание того, что к нему привело.
На практике лучший подход к поддержанию хорошего сообщения о фиксации — использовать git add -p и git commit --amend, чтобы сформулировать надёжный набор изменений. Это позволяет собирать изменение по мере поступления информации.
Если вы объединяете серию коммитов, не просто отправьте это. Перепишите сообщение о фиксации, как будто серия коммитов была одним гениальным ходом.
При этом нет требования иметь один коммит для запроса на включение, пока каждый коммит рассказывает историю. Например, если есть функция, требующая пакета, может иметь смысл поместить пакет в отдельный коммит, а затем сделать последующий коммит, который его использует.
Помните, вы рассказываете часть истории с помощью сообщения о фиксации. Не делайте свою главу странной.
Комментарии проверки кода могут быть добавлены к вашему запросу на включение. Обсудите, затем внесите предложенные изменения и отправьте дополнительные коммиты в свою ветку функций. Оставьте комментарий после отправки. Новые коммиты отображаются в запросе на включение автоматически, но рецензенты уведомляются только тогда, когда вы комментируете.
Запросы на включение должны быть аккуратно перебазированы поверх основной ветки без смешивания нескольких веток в PR.
Совет Git: если ваш PR больше не объединяется чисто, используйте rebase master в своей функциональной ветке, чтобы обновить свой запрос на включение, вместо merge master.
Перед тем как сделать запрос на включение, объедините свои коммиты в логические единицы работы с помощью git rebase -i и git push -f. Логическая единица работы — это согласованный набор исправлений, которые следует рассматривать вместе: например, обновление версии сторонней зависимости и использование её теперь доступной новой функции составляют две отдельные единицы работы. Реализация новой функции и вызов её в другом файле составляют одну логическую единицу работы. Подавляющее большинство представлений должно иметь один коммит, поэтому, если сомневаетесь: объедините до одного.
После каждого коммита убедитесь, что тест пройден. Включайте изменения документации в тот же запрос на включение, чтобы при возврате были удалены все следы функции или исправления.
Включите ссылку на задачу вроде Closes #XXXX или Fixes #XXXX в коммитах. Закрыть задачу.
При автоматическом слиянии задача также закрывается.
Пожалуйста, ознакомьтесь с разделом Стиль кодирования для получения дополнительных рекомендаций.
Сопровождающие GLC используют LGTM (Looks Good To Me) в комментариях к проверке кода, чтобы указать на принятие.
Подпись представляет собой простую строку в конце пояснения к патчу. Ваша подпись подтверждает, что вы написали патч или иным образом имеете право передать его как патч с открытым исходным кодом. Правила довольно просты: если вы можете подтвердить следующее (с сайта developercertificate.org):
Сертификат разработчика о происхождении
Версия 1.1
Авторские права (C) 2004, 2006 The Linux Foundation и её участники. 1 Леттерман Драйв Сьют D4700 Сан-Франциско, Калифорния, 94129
Каждому разрешено копировать и распространять дословные копии этого документа лицензии, но изменение запрещено.
Сертификат разработчика о происхождении 1.1
Внося вклад в этот проект, я подтверждаю, что:
(a) Вклад был полностью или частично создан мной, и у меня есть право представить его под открытой лицензией, указанной в файле; или
(b) Вклад основан на предыдущей работе, которая, насколько мне известно, защищена соответствующей лицензией с открытым исходным кодом, и у меня есть право в соответствии с этой лицензией представить эту работу с изменениями, полностью или частично созданную мной, под той же лицензией с открытым исходным кодом (если только мне не разрешено представлять её по другой лицензии), как указано в файле; или
(c) Вклад был предоставлен мне непосредственно другим лицом, которое подтвердило (а), (b) или (c), и я не вносил в него изменений.
(d) Я понимаю и соглашаюсь с тем, что этот проект и вклад являются публичными, и что запись о вкладе (включая всю личную информацию, которую я предоставляю вместе с ним, включая мою подпись) ведётся бессрочно и может быть распространена в соответствии с этим проектом или задействованными лицензиями с открытым исходным кодом.
Затем вы просто добавляете строку к каждому сообщению git commit:
Signed-off-by: Ri Xu https://xuri.me
Используйте своё настоящее имя (извините, никаких псевдонимов или анонимных вкладов).
Если вы установите свои git-конфигурации user.name и user.email, вы сможете автоматически подписать свой коммит с помощью git commit -s.
Во-первых, все сопровождающие имеют 3 вещи:
Сопровождающих часто недооценивают, потому что их работу труднее оценить. Легко оценить действительно крутую и технически продвинутую функцию. Труднее оценить отсутствие ошибок, медленное, но устойчивое улучшение стабильности или надёжность процесса выпуска. Но эти вещи отличают хороший проект от отличного.
Не забывайте: быть сопровождающим — это инвестиция времени. Убедитесь, что у вас будет время, чтобы быть доступным. Вам не нужно быть сопровождающим, чтобы внести свой вклад в проект!
Если вы хотите стать сопровождающим, свяжитесь с xuri.me и расскажите о себе.
Мы хотим, чтобы сообщество было потрясающим, растущим и совместным. Нам нужна ваша помощь, чтобы сохранить его таким. Чтобы помочь в этом, мы разработали несколько общих рекомендаций для сообщества в целом:
Будьте милы: будьте вежливы, уважительны и вежливы по отношению к другим членам сообщества: региональное, расовое, гендерное или другое насилие недопустимо. Нам нравятся милые люди гораздо больше, чем злые!
Поощряйте разнообразие и участие: сделайте так, чтобы каждый член нашего сообщества чувствовал себя желанным гостем, независимо от его происхождения и степени его вклада, и делайте всё возможное, чтобы поощрять участие в нашем сообществе.
Соблюдайте закон: в основном, не втягивайте нас в неприятности. Делитесь только контентом, который вам принадлежит, не делитесь личной или конфиденциальной информацией и не... Нарушение правил — метод трёх предупреждений
Цель этого раздела не в том, чтобы найти возможности наказать людей, но нам нужен справедливый способ справиться с теми, кто делает наше сообщество хуже.
Примечания:
Если явно не указано иное, мы следуем всем правилам кодирования сообщества Go. Хотя некоторые из этих стандартов могут показаться произвольными, они каким-то образом приводят к надёжной и согласованной кодовой базе.
Возможно, кодовая база в настоящее время не соответствует этим правилам. Мы не ищем массивный PR, который это исправит, поскольку это противоречит духу правил. Все новые вклады должны прилагать максимум усилий для очистки и улучшения кодовой базы. Очевидно, применяйте своё лучшее суждение. Помните, цель здесь — сделать кодовую базу более удобной для навигации и понимания людьми. Всегда имейте это в виду, когда побуждаете других соблюдать правила.
Правила:
Весь код должен быть отформатирован с помощью gofmt -s.
Весь код должен пройти стандартные уровни golint.
Весь код должен следовать правилам, описанным в Effective Go и Go Code Review Comments.
Комментируйте код. Расскажите нам, почему, историю и контекст.
Документируйте все объявления и методы, даже частные. Объявляйте ожидания, предостережения и всё остальное, что может быть важным. Если тип экспортируется, наличие комментариев уже там гарантирует, что он готов.
Длина имени переменной должна быть пропорциональна её контексту и не более. noCommaALongVariableNameLikeThisIsNotMoreClearWhenASimpleCommentWouldDo. На практике короткие методы будут иметь короткие имена переменных, а глобальные — более длинные имена.
Никаких подчёркиваний в названиях пакетов. Если вам нужно составное имя, сделайте шаг назад и ещё раз подумайте, зачем вам нужно составное имя. Если вы всё ещё думаете, что вам нужно составное имя, избавьтесь от подчёркивания.
Никаких утилит или вспомогательных пакетов. Если функция недостаточно универсальна, чтобы оправдать собственный пакет, она недостаточно универсально написана, чтобы быть частью пакета утилит. Просто оставьте её неэкспортированной и хорошо задокументированной.
Все тесты должны выполняться с go test и снаружи. Тулинг не должен быть обязательным. Нет, нам не нужен ещё один фреймворк для модульного тестирования. Пакеты утверждений приемлемы, если они обеспечивают реальное добавочное значение.
Хотя мы называем это «правилами», на самом деле это просто рекомендации. Поскольку вы прочитали все правила, теперь вы это знаете.
Если вам трудно проникнуться идиоматикой Go, рекомендуем прочитать Effective Go. Также отличным ресурсом является Go Blog. Верить на слово (дословно: пить кул-эйд) гораздо проще, чем искать информацию самостоятельно.
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )