Внесение вклада в GitLab

Это руководство подробно объясняет, как вносить вклад в проект GitLab.

Если вы хотите узнать, как команда GitLab обрабатывает вклады, обратитесь к процессу взаимодействия с вкладами GitLab.

Лицензионное соглашение для вкладчиков

Подавая код как частное лицо, вы соглашаетесь с личным лицензионным соглашением для вкладчиков. Подавая код как юридическое лицо, вы соглашаетесь с корпоративным лицензионным соглашением для вкладчиков.

Раскрытие уязвимостей безопасности

Пожалуйста, сообщите о подозрительных уязвимостях безопасности в конфиденциальном порядке на адрес support@gitlab.com, также см. раздел раскрытия на сайте GitLab.com. Пожалуйста, не создавайте публично доступные проблемы для подозрительных уязвимостей безопасности.

Политика закрытия проблем и запросов слияния

GitLab — это популярный открытый проект, а возможности для обработки проблем и запросов слияния ограничены. Из уважения к нашим добровольцам, проблемы и запросы слияния, не соответствующие указанным ниже рекомендациям, могут быть закрыты без уведомления.

Пожалуйста, относитесь к нашим добровольцам с учтивостью и уважением, что поможет быстрее решить вашу проблему.Проблемы и запросы на слияние должны быть на английском языке и содержать подходящий язык для всех возрастных групп.

Система отслеживания проблем

Для получения помощи по конкретной проблеме используйте каналы, указанные в разделе получения помощи в README. Профессиональные подписки на поддержку и консалтинговые услуги доступны на GitLab.com.

Система отслеживания проблем предназначена только для очевидных ошибок в последней стабильной или разработочной версии GitLab. Если что-то работает некорректно, но это не является регрессией по сравнению со старыми версиями GitLab, пожалуйста, не открывайте проблему, а отправьте запрос на новую функцию. Когда вы отправляете проблему, пожалуйста, следуйте рекомендациям по отправке проблем, указанным ниже. Не все проблемы будут рассмотрены, и ваша проблема более вероятна будет рассмотрена, если вы отправите запрос на слияние, который частично или полностью решает проблему. Проблемы можно создавать как на gitlab.com, так и на github.com.Не используйте трекер проблем для запросов новых функций. У нас есть специальный форум для запросов функций для этой цели. Пожалуйста, делайте запросы функций максимально простыми и лаконичными; сложные запросы могут быть отредактированы для упрощения.Если вы можете предоставить слияние с проверенным решением или слияние с провалившимся тестом вместо создания проблемы, это будет полезнее. Если вы не уверены, где публиковать, сначала отправьте сообщение на почтовый список рассылки или Stack Overflow. Там много полезных пользователей GitLab, которые могут быстро помочь вам. Если ваша конкретная проблема окажется багом, она найдёт своё место там.

Правила использования трекера проблем**Поиск аналогичных записей в трекере проблем** перед тем, как создать свою собственную, вероятность того, что кто-то еще столкнулся с такой же проблемой, очень высока. Поддержите других с помощью :+1: и/или присоединьтесь к обсуждению. Пожалуйста, отправляйте проблемы в следующем формате (в качестве первого поста):

1. Краткое описание: Опишите вашу проблему в одном предложении (что пошло не так, что вы ожидали получить).
2. Шаги воспроизведения: Как можно воспроизвести проблему, желательно на виртуальной машине с использованием Vagrant (начните свой запрос командой: vagrant destroy && vagrant up && vagrant ssh).
3. Ожидаемое поведение: Опишите вашу проблему подробно.
4. Наблюдаемое поведение.
5. Релевантные логи и/или скриншоты: Пожалуйста, используйте блоки кода (```) для форматирования вывода консоли, логов и кода, поскольку это очень трудно читать иначе.
6. Выходные данные проверок
   • Результаты проверки приложения GitLab (Application Check) (sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production); мы будем исследовать только те случаи, когда тесты проходят успешно.
   • Версию GitLab, которую вы используете; мы будем рассматривать проблемы только в последних стабильных и разрабатываемых версиях согласно политике обслуживания (maintenance policy). * Укажите последний коммит SHA1 версии GitLab, которую вы использовали для воспроизведения проблемы (получается с помощью страницы справки).
     • Опишите вашу среду (используйте соответствующие части от sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production).
7. Возможные исправления: Если возможно, приведите ссылку на строку кода, которая может быть ответственной за проблему. ## Запросы на слияниеМы приветствуем запросы на слияние с исправлениями и улучшениями кода, тестов и/или документации GitLab. Функции, для которых мы особенно хотели бы получить запросы на слияние, указаны со статусом "прием запросов на слияние" на нашем форуме запросов на функции здесь, но также приветствуются и другие улучшения. Если вы хотите добавить новую функцию, которая не отмечена как таковая, лучше всего создать проблему обратной связи (если её ещё нет) и оставить комментарий, чтобы её пометили как принимающую запросы на слияние. Пожалуйста, приложите скриншоты или макеты, если функция будет изменять интерфейс пользователя.

Запросы на слияние можно отправить либо на gitlab.com, либо на github.com.

Правила для запросов на слияние

Если возможно, пожалуйста, отправьте запрос на слияние с исправлением или улучшением, включая тесты. Если вы не знаете, как исправить проблему, но можете написать тест, который раскрывает эту проблему, это тоже будет принято. В целом, исправления ошибок, включающие регрессионные тесты, обычно сливаются быстро, а новые функции без должных тестов имеют наименьшие шансы получить своевременную обратную связь. Процесс создания запроса на слияние следующий:1. Создайте форк проекта на GitLab Cloud

1. Создайте ветку с новой функциональностью
2. Напишите тесты и код
3. Добавьте ваши изменения в CHANGELOG
4. Если у вас несколько коммитов, объедините их в один коммит с помощью squash
5. Отправьте коммит на ваш форк
6. Подайте запрос на слияние (MR) в основную ветку
7. Заголовок MR должен описывать изменения, которые вы хотите внести
8. Описание MR должно содержать мотивацию ваших изменений и метод, которым вы достигли этих изменений
9. Если MR меняет интерфейс пользователя, он должен включать скриншоты до и после изменений
10. Если MR меняет CSS-классы, пожалуйста, приложите список затронутых страниц grep css-class ./app -R
11. Ссылка на относящиеся проблемы и/или запросы на функции из описания MR и оставьте комментарий на них с обратной ссылкой на MR
12. Будьте готовы ответить на вопросы и внедрить обратную связь даже если она поступает неделями или месяцами после вашего подачи MR
13. Если ваш MR затрагивает код, выполняющий команды командной строки, убедитесь, что он соответствует правилам выполнения команд командной строки. Официальный период слияния начинается в начале месяца с 1 по 7 число. Лучшее время для отправки запроса на слияние (Merge Request) и быстрого получения обратной связи.До этого времени команда GitLab.com занимается решением задач, возникающих после ежемесячного выпуска, такими как помощь подписчикам при обновлении, выпуск версии Enterprise Edition и обновление GitLab Cloud. После 7 числа уже ближе к дате выхода следующей версии, что означает меньший временной промежуток для исправления проблем, вызванных объединением крупных новых функций.Пожалуйста, сделайте изменения в одном Merge Request как можно меньше. Если вы хотите внести крупную функцию, очень внимательно рассмотрите минимально жизнеспособное изменение. Можно ли разделить функциональность? Можно ли отправить только код серверной части/API? Можно ли начать с очень простого интерфейса? Чем меньше будет Merge Request, тем больше шансов его одобрения. После этого вы можете отправить дополнительные Merge Requests для улучшения.

Для примеров обратной связи по Merge Requests просмотрите уже закрытые Merge Requests. Убедитесь, что ваш Merge Request соответствует следующим критериям принятия вклада.

Пожалуйста, оформите описание вашего Merge Request следующим образом:

1. Что делает этот Merge Request?
2. Есть ли точки в коде, которые требуют двойной проверки со стороны рецензента?
3. Почему был необходим этот Merge Request?
4. Какие номера связанных задач/запросов на новую функцию?
5. Скриншоты (если применимо)

Критерии принятия вклада1. Изменение должно быть минимальным (см. вышеупомянутый абзац за подробностями).

1. Включены правильные тесты, и все тесты должны проходить (кроме случаев, когда тест предназначен для выявления ошибки в существующем коде).
2. Может быть слито без проблем (если нет, пожалуйста используйте: git rebase master).
3. Не нарушает ни одну существующую функциональность.
4. Исправляет конкретную проблему или реализует конкретную функцию (не следует объединять вещи, отправьте отдельные Merge Requests, если это необходимо).
5. Поддерживает чистое и хорошо структурированное основание кода GitLab.
6. Включает функциональность, которую мы считаем полезной для других пользователей.
7. Не добавляет конфигурационные опции, поскольку они усложняют будущие изменения.
8. Содержит один коммит (пожалуйста используйте git rebase -i, чтобы свести коммиты).
9. Соответствует следующим руководствам по стилю кодирования ## Стилевые руководства
10. Ruby
11. Rails
12. Форматирование
13. Именование
14. Тестирование
15. CoffeeScript
16. Команды командной строки