Создать pull request visual studio
Это руководство научит вас делать изменения в проекте на GitHub. Описываемый процесс предлагает лучшие практики , и является достаточно распространённым — вы сможете применять его за пределами нашего сообщества. В проектах сообщества придерживаться такого процесса очень рекомендуется.
Сначала мы приведём высокоуровневое описание процесса , а затем подробно опишем каждый этап.
Предполагается знание основ системы контроля версий Git. Если вы ещё не работали с Git, мы дадим ссылки на официальную русскоязычную документацию по необходимым командам.
Вот процесс с высоты птичьего полёта.
- Форкните проект.
- Склонируйте репозиторий.
- Создайте ветку для своей работы.
- Сделайте необходимые изменения в файлах — коде , документации , тестах. Закоммитьте их в только что созданную ветку.
- Убедитесь , что проект работает после ваших изменений.
- Сделайте Pull Request.
- Обсудите его с рецензентом в процессе Code Review. При необходимости , внесите изменения в свой Pull Request.
- Когда все довольны , Pull Request принимают — с этого момента ваши изменения попали в исходный репозиторий ( upstream) и являются частью проекта.
Работа над задачей закончена!
Теперь рассмотрим каждый этап подробнее.
Форкаем проект
Вы не можете отправлять коммиты ( git push ) напрямую в исходный репозиторий. По желанию хозяин проекта может это разрешить , но обычно доступ на запись есть только у людей , поддерживающих проект , а все остальные работают через Pull Request’ы ( «запросы на вливание изменений»; о них — ниже).
Поэтому мы форкаем проект — это создаст копию репозитория в вашем аккаунте. При этом у вас появится доступ на запись в вашу копию.
Через мгновение вы будете перенаправлены на страницу вашего форка.
Клонируем репозиторий
Затем выполняем команду в терминале ( или командной строке Windows):
git clone <вставляем_URL>
Репозиторий склонируется в под-директорию текущей директории. Например , если репозиторий называется foobar , у вас появится каталог foobar .
Создаём ветку
Ветка по умолчанию — master . Чтобы изменениями было проще управлять и они не смешивались друг с другом , создадим отдельную ветку , где и будем работать. При этом ветку стоит назвать так , чтобы имя говорило о её назначении.
Теперь заходим в наш склонированный репозиторий и создаём ветку:
Вторая команда создаст ветку и перейдёт на неё ( сделает checkout).
Если после этого выполнить git status , он покажет
Эту команду стоит запомнить — когда не понимаете , в каком состоянии репозиторий, просто выполните её. Чаще всего в её выводе git покажет другие команды, которые делают то , что вы ( скорее всего) и хотите сделать.
Делаем изменения
Теперь приступаем к работе. Редактируем код , обновляем документацию , чиним тесты , дополняем README.
Эти изменения мы коммитим в нашу ветку. Как это сделать — ниже.
При этом старайтесь делать коммиты часто , а сами коммиты — небольшими по объёму. Каждый коммит должен делать ровно одну вещь , и при этом поддерживать работоспособность проекта. Стремиться нужно к тому , чтобы в будущем можно было перейти на любой коммит и получить рабочий проект.
Если у вас сразу не получается придерживаться такой дисциплины , или изменения затрагивают весь проект « насквозь», допустимо ломать проект и постепенно чинить его в следующих коммитах.
Если вы уже достаточно разбираетесь в Git, такие не-атомарные изменения потом нужно объединить в один коммит с помощью interactive rebase и squash.
Итак , после редактирования файлов мы имеем следующую ситуацию ( это вывод git status ):
В выводе есть все необходимые вам команды:
- git add <file>. добавляет файл в содержимое коммита , который вы собираетесь записать
- git checkout -- <file>. откатывает ваши изменения файла
Она должна иметь вид <Глагол в настоящем времени, первом лице, множественном числе> <объект изменения> . Говорим о том , что мы делаем в этом коммите: [мы] исправляем ошибку , [мы] добавляем возможность , [мы] обновляем документацию.
git log --oneline выводит историю в формате « 1 коммит — 1 строка на экране». При этом он использует в качестве описания коммита первую строку — краткое описание. Поэтому оно обязательно должно быть отделено пустой строкой от остального описания — иначе однострочный вывод разъедется.
Проверяем изменения
Когда вы сделали правки , стоит их проверить — если только это не что-то абсолютно тривиальное.
Для этого нужно собрать проект и запустить тесты , если они есть. В любом случае стоит проверить работу кода , который вы написали или изменили , запустив программу или вызвав библиотеку.
Если проект — это статически генерируемый сайт , то сгенерируйте его локально и убедитесь , что ничего не отвалилось и вёрстка не разъехалась. Если книга — то же самое. Смотрите по крайней мере на те места , которые вы правили.
Создаём Pull Request
Когда работа и проверка закончены , пора создавать Pull Request. Pull Request — это запрос на вливание изменений из вашей ветки в основную ветку исходного репозитория. Таким образом они попадут к хозяевам проекта.
Чтобы создать Pull Request, зайдём на страницу вашего форка. Справа от выпадающего меню с выбором ветки есть кнопка « New pull request».
Вы попадаете в окно сравнения веток.
Вот элементы этого окна , по порядку:
Дальше просмотрите изменения — то ли это , что вы делали? Если да , то нажимайте кнопку « Create pull request». В моём примере её нет , т. к. ветки в форке и в оригинале находятся в одинаковом состоянии. В вашем же случае внизу будет список коммитов , которые попадут в исходный репозиторий , и , на других вкладках — сами изменения и комментарии к изменениям.
Затем нажимаем « Create pull request». Он создаётся , о нём приходит уведомление людям , поддерживающим проект , и он становится виден в исходном репозитории на вкладке « Pull requests». С этого момента начинается рецензирование изменений ( code review).
Подсказка: если сразу после того , как вы отправили ветку в свой репозиторий ( git push origin ) зайти на страницу репозитория , там будет предложение создать Pull Request на вливание недавно отправленной ветки в master. Сделать это можно как в вашем форке , так и в исходном репозитории. Это будет отдельная кнопка вверху , и при её нажатии в качестве ветки для слияния будет указана та , куда вы делали git push .
Участвуем в Code Review
Со стороны автора Pull Request ( а раз вы читаете это руководство , вы наверняка автор) требуется с пониманием относиться к комментариям рецензента — они направлены на повышение качества проекта. Если ошибка в сборке выявляется в процессе рецензирования , это гораздо лучше , чем если она попадёт в репозиторий, а следующий человек , который попытается поучаствовать в проекте , не сможет этого сделать из-за той самой ошибки. Да и это касается не только сборки , разумеется.
Также отмечу , что общаться в комментариях к PR следует вежливо и с уважением. Даже если вы общаетесь не с рецензентом. Не надо делать разнообразные далекоидущие выводы относительно пола , возраста , расы , интеллектуальных способностей и других черт человека. Если вы будете грубить рецензенту , в следующий раз он просто не захочет смотреть PR от вас. Не забывайте , что рецензирование — это тоже работа. Так что будьте добры и уважайте труд людей — они делают это бесплатно.
Если кто-то ведёт себя неадекватно — не медлите. Сначала сообщите об этом собеседнику и призовите его к благоразумию. Если не сработало — смело обращайтесь к рецензенту или к автору данного текста ( Панкову Михаилу — @mkpankov). Это можно сделать в нашем чате.
Пожелание относительно процесса рецензирования — постарайтесь не сильно затягивать с ответами на комментарии или изменением указанных вещей.
Почему это важно? Автор PR хорошо разбирается в том , что он сделал , а если процесс затягивается на недели и месяцы , высока вероятность , что или автор , или рецензент отвлекутся на другие вещи , а обратный вход в контекст изменений тоже стоит усилий и времени. « Другие вещи» здесь — это вся остальная жизнь человека. Может на работе аврал , может личные проблемы , может заболел. В итоге может получиться так , что ваш PR навеки повиснет в неготовом состоянии и так и не будет влит. Конечно , нам бы этого не хотелось.
В отдельных случаях стоит обсудить спорный момент в чате , нежели перебрасываться комментариями на GitHub. Это гораздо быстрее , и объяснить свою позицию в интерактивном общении проще.
Также стоит отметить , что процесс рецензирования итеративен по природе. То , что рецензент написал комментарий к какой-то строке на пятой итерации , хотя она не менялась с первой , не значит , что он захотел придраться. Возможно , в результате окружающих изменений она потеряла смысл , или нужно изменить стиль фразы в документации , чтобы он согласовался с окружающим текстом. Также , часто просто сложно увидеть все места , требующие правки , с первого раза — внимательность и память любого человека ограничены. По мере того , как самые заметные вещи исправляют , внимание уделяется менее заметным — это нормально.
В нашем сообществе не принято наезжать на новичков , и мы всегда стараемся помочь. Не пугайтесь рецензирования — выше написано много слов , но на деле достаточно просто адекватно себя вести и не забивать на исправления.
Когда этот этап завершается , рецензент нажимает кнопку « Merge Pull Request». Ваши изменения влиты в основной репозиторий проекта.
Поздравляем! Теперь вы полноправный участник проекта.
Завершение работы
После вливания PR нужно прибраться в репозитории. Если ваши изменения самодостаточны и после PR не требуется продолжать работу дальше , стоит удалить ветку. Как вы помните , мы создали её раньше , чтобы удобнее управлять изменениями.
Но сначала лучше обновить вашу локальную master-ветку — тогда git убедится, что ваша ветка уже влита в master , и не будет предупреждать , что вы можете потерять свои изменения.
Итак , обновляем нашу локальную рабочую копию. Для этого добавим ещё один remote — так называется удалённый репозиторий. Сейчас он у вас только один — origin , и он указывает на ваш форк. Добавим remote с именем upstream , который будет указывать на исходный репозиторий:
Как и во многих других проектах с открытым исходным кодом, в сообществе Visual Studio Code используются запросы на принятие изменений. С их помощью разработчики совместно исправляют ошибки и добавляют новые функции. Недавно мы обновили общедоступную пробную версию GitHub Pull Requests for Visual Studio Code, тем самым устранив проблему, с которой мы и миллионы разработчиков сталкиваемся каждый день: невозможность просматривать исходный код там, где он был написан, — в редакторе.
С прошлой весны наша команда занимается созданием новой интегрированной системы запросов, чтобы повысить удобство совместной работы и предоставить возможность комментировать, просматривать и проверять запросы на включение GitHub напрямую из Visual Studio Code.
Просмотр и обработка запросов на включение
Новое расширение GitHub Pull Requests позволяет просматривать и обрабатывать запросы на включение (pull request, PR) напрямую из Visual Studio Code, а также:
- Подключать Visual Studio Code к GitHub и входить в личный кабинет оттуда же.
- Составлять списки PR и просматривать их в Visual Studio Code.
- Работать с PR прямо из редактора, добавлять комментарии с использованием разметки Markdown.
- Проверять PR непосредственно в редакторе в новом локальном режиме checkout and run, используя разнообразные функции языка программирования, например, Go To Definition и IntelliSense.
- Интегрировать терминал, чтобы интерфейс Visual Studio Code и инструменты командной строки, такие как git, работали вместе.
Совместная работа с командой GitHub
Приступив к переносу запросов на принятие изменений с Visual Studio Code в прошлом году, мы обратились к нашим партнерам. Когда выяснилось, что разработчики редактора GitHub имеют схожие планы, мы объединили наши усилия в апреле для создания новой системы запросов на принятие изменений в Visual Studio Code. Используя набор новых расширений API для Visual Studio Code, мы разработали новое расширение для создания и просмотра запросов на принятие изменений непосредственно в Visual Studio Code.
Более удобная работа с запросами на принятие изменений
На данный момент при проверке исходного кода в большинстве случаев мы вынуждены выходить из «родного» редактора и использовать для просмотра упрощенный веб-интерфейс или дополнительный инструмент, в котором изменения отображаются в другом редакторе. Да, внесенные правки показаны здесь наглядно, но мы не получаем полный контекст фрагмента, в котором они сделаны, и не видим, как они влияют на окружающий исходный код. Оказавшись вне привычной среды разработки, мы лишаемся возможности использовать знакомые сочетания клавиш и настройки. И самое главное, мы не можем выполнять навигацию по исходному коду и проверять, действительно ли просматриваемые изменения работают так, как задумано.
Теперь ситуация улучшилась благодаря новому расширению с новым проводником Pull Requests, который находится в окне Source Control в Visual Studio Code. Здесь мы можем просматривать запросы и обрабатывать их.
Новые открытые расширения API
Наша новая система запросов на принятие изменений использует наборы расширений API, с помощью которых разработчики расширений для Visual Studio Code могут создавать расширения для управления запросами на принятие изменений и связанными с ними метаданными. Благодаря открытой модели расширения поставщики запросов на принятие изменений работают аналогично поставщикам контроля версий: каждый получает возможность написать расширение для Visual Studio Code, позволяющее оставлять комментарии и просматривать исходный код, размещенный на их платформе. Более полная информация о новых API представлена в наших Заметках о выпуске за август 2018 года.
Если вы заинтересовались этим вопросом, то можете узнать больше о выпуске новых API и процессах расширения API здесь.
Перспективы
Мы рады наконец добавить возможность работы с запросами на принятие изменений в Visual Studio Code, поскольку считаем, что это упростит проверку исходного кода. Расширение GitHub – это только первый шаг по интеграции поставщиков платформ контроля версий для проверки кода в Visual Studio Code.
Ознакомьтесь с общедоступной пробной версией GitHub Pull Requests for Visual Studio Code. Как обычно, мы будем рады получить ваши отзывы, поэтому смело обращайтесь к нам на GitHub или в Твиттере @code.
Что такое запрос на вытягивание?
Запрос на вытягивание (PR) - это метод отправки вкладов в открытый проект разработки. Это происходит, когда разработчик запрашивает изменения, зафиксированные во внешнем репозитории, для рассмотрения для включения в основной репозиторий проекта после экспертной оценки.
Что такое запрос на перенос Visual Studio?
Запрос на включение для Visual Studio. Расширение Pull Requests для Visual Studio предоставляет набор новых инструментов проверки кода для IDE. С помощью этого расширения вы можете: Просматривать историю изменений во время написания кода. Внесите изменения в реальном времени и установите точки останова в представлении различий.
Как мне отменить объединенный запрос на перенос?
Отмена запроса на перенос Под именем вашего репозитория щелкните Запросы на извлечение. В списке «Запросы на извлечение» щелкните запрос на извлечение, который нужно отменить. Внизу запроса на извлечение нажмите Вернуть. Объедините полученный запрос на перенос. Дополнительную информацию см. В разделе «Объединение запроса на перенос».
Как проверить запрос на перенос перед объединением?
Решение Шаг 1. Получите URL-адрес запроса на слияние. Шаг 2: Войдите в ваш локальный репозиторий (у меня "sorcerial") через командную строку. Шаг 3. Если вы хотите проверить запрос на извлечение, поэкспериментировать с ним и сначала протестировать его, просто запустите команду - git checkout FETCH_HEAD:
Что такое запрос на извлечение в DevOps?
Запросы на извлечение позвольте вашей команде дать отзыв об изменениях в функциональных ветках, прежде чем объединять код в основную ветку. Рецензенты могут просматривать предлагаемые изменения, оставлять комментарии и голосовать за одобрение или отклонение кода. Azure DevOps предоставляет широкие возможности для создания, проверки и утверждения запросов на вытягивание.
Как просмотреть запрос на вытягивание в Visual Studio?
Просмотр запроса на вытягивание в Visual Studio Откройте решение в репозитории GitHub. Откройте Team Explorer и нажмите кнопку Pull Requests, чтобы открыть панель GitHub. Щелкните заголовок запроса на перенос, который нужно просмотреть.
Что такое запрос на перенос в битбакете?
Запросы на вытягивание - это функция, которая упрощает совместную работу разработчиков с помощью Bitbucket. Как только их функциональная ветка готова, разработчик отправляет запрос на вытягивание через свою учетную запись Bitbucket. Это позволяет всем участникам узнать, что им необходимо просмотреть код и объединить его с основной веткой.
Что такое git merge request?
Merge requests позволяют визуализировать и совместно работать над предлагаемыми изменениями в существующем исходном коде. as фиксируется в данной ветке Git. Запрос на слияние (MR) является основой GitLab как платформы для совместной работы над кодом и управления версиями. Это так же просто, как следует из названия: запрос на объединение одной ветки с другой.
Можете ли вы утвердить свой собственный запрос на вытягивание?
Пользователь может утвердить собственный запрос на вытягивание, если они настроены в разделе «Автоматически включать рецензентов кода». Мы настроили его так, чтобы был хотя бы 1 рецензент и пользователи не могли утверждать свои изменения.
Как изменить фиксацию в запросе на извлечение GitHub Добавьте еще одну фиксацию в эту ветку, а затем нажмите на эту ветку. Вручную исправьте свои изменения, исправьте и принудительно нажмите. Добавьте еще одну фиксацию, а затем сквош зафиксирует. В интерактивном режиме проверьте предыдущую фиксацию, удалите ненужные строки, обработайте, измените и принудительно нажмите. Интерактивное перебазирование.
Как долго должен длиться запрос на вытягивание?
Как видно из приведенной выше диаграммы, проверка запросов на вытягивание с более чем 250 строками изменений обычно занимает более часа. Как обновить пул-реквест?
Чтобы обновить заголовок пул-реквеста в репозитории, запустите команду update-pull-request-title, указав: ID пул-реквеста (с параметром --pull- параметр request-id). Чтобы обновить описание запроса на перенос, выполните команду update-pull-request-description, указав:
Могу ли я объединить свой собственный запрос на перенос?
Как вы реализуете процесс проверки кода?
10 советов, которые помогут вам повысить эффективность коллегиальной проверки кода Проверяйте меньше более 400 строк кода за раз. Не торопитесь. Не просматривайте за раз более 60 минут. Ставьте цели и фиксируйте показатели. Авторы должны аннотировать исходный код перед рецензией. Используйте контрольные списки. Наладить процесс исправления обнаруженных дефектов.
Видео на ваш вопрос: Как создать пулреквест в Visual Studio 2019?
Перевод статьи «How to make your first pull request on GitHub».
Что такое форк?
Когда нам нравится чей-то репозиторий и мы хотели бы иметь его в собственном аккаунте на GitHub, мы делаем форк («вилку») этого репозитория, чтобы иметь возможность работать с ним отдельно.
Когда мы делаем форк репозитория, мы получаем экземпляр всего репозитория, со всей его историей. После форка мы можем делать с ним все, что угодно: оригинальная версия при этом не будет задета.
Что такое пул-реквест?
Пул-реквесты нужны. Когда мы хотим принять участие в групповой разработке проектов с открытым исходным кодом.
Например, пользователь Павел делает форк репозитория ThanoshanMV (автора статьи, — прим. перев.) и вносит изменения в свой экземпляр. После этого Павел отсылает пул-реквест ThanoshanMV, который может либо принять его, либо отклонить. По сути это что-то вроде письма «Не будете ли вы так любезны, уважаемый ThanoshanMV, внести мои изменения в свой оригинальный репозиторий?»
Как можно стать контрибьютором проекта?
Участие в проекте с открытым исходным кодом не обязательно предполагает работу именно с кодом. Контрибьютором (участником) можно стать и другими способами, некоторые из них описаны ниже.
- Дизайн. Можно создать макеты проекта, чтобы повысить удобство его использования, усовершенствовать навигацию или меню, создать рисунки для лого или футболок, написать руководство по стилю проекта.
- Писательство. Можно написать документацию проекта или улучшить уже существующую, перевести документацию на свой язык, создать новостную рассылку для проекта, написать руководства для пользователей или заняться формированием папки с примерами использования.
- Организаторские задачи. Можно связывать дублирующиеся issues, предлагать новые метки для issues, предлагать закрытие старых, но еще открытых issues, задавать вопросы в новых — чтобы подстегивать развитие дискуссии.
- Помощь другим людям. Можно отвечать на вопросы в открытых issues, проверять код других разработчиков, предлагать помощь в качестве наставника.
- Написание кода. Можно помогать в решении возникших проблем, предлагать создание новых фич, а также улучшать инструментарий и тестирование.
Давайте создадим наш первый пул-реквест!
1. Форк репозитория
Чтобы сделать форк репозитория, нужно нажать кнопку «Fork» в верху страницы. Таким образом вы создадите экземпляр всего этого репозитория в своем аккаунте.
2. Клонирование репозитория
Когда репозиторий уже есть в вашем аккаунте, вы можете клонировать его на свою машину и в дальнейшем работать с ним локально.
Чтобы клонировать репозиторий, нажмите кнопку «clone» и скопируйте ссылку.
Откройте терминал и запустите следующую команду. С ее помощью репозиторий будет клонирован на вашу машину.
Теперь у вас есть копия ветки master основного онлайн-репозитория проекта.
Переходим в клонированную директорию:
3. Создание ветки
При работе с репозиторием хорошей практикой считается создание отдельной ветки для внесения изменений, причем это не зависит от размеров проекта.
Имя ветки должно быть коротким и отражать те изменения, которые вы вносите.
Создадим ветку при помощи команды git checkout:
4. Внесение изменений и коммит
Внесите необходимы изменения в проект и сохраните их. Затем запустите команду git status: вы увидите внесенные изменения.
Добавьте эти изменения в только что созданную ветку при помощи команды git add:
Теперь вы можете сделать коммит этих изменений при помощи команды git commit:
5. Отправка изменений на GitHub
Имя данного удаленного репозитория — «origin».
6. Создание пул-реквеста
Перейдите в свой репозиторий на GitHub. Там есть кнопка «Compare & pull request» — кликните ее.
Введите необходимые детали относительно того, что именно вы сделали (чтобы поставить ссылку на issues, возмользуйтесь знаком «решетки»). После этого можно нажать кнопку подтверждения внизу.
Поздравляю! Вы создали свой первый пул-реквест. Если его примут, вы получите уведомление по электронной почте.
7. Синхронизация вашего форка с основной веткой
Прежде чем создавать пул-реквест в оригинальный репозиторий, нужно синхронизировать свой экземпляр этого репозитория с оригинальным.
Даже если вы не собираетесь отправлять пул-реквест в оригинальный репозиторий, все равно лучше синхронизироваться с ним. Со времени создания форка в оригинальном репозитории могли добавиться новые фичи, а также могли быть исправлены какие-то баги.
Проделайте следующие действия, чтобы обновить свой репозиторий и внести соответствующие изменения в свою ветку master:
1. Для начала, проверьте, в какой ветке вы находитесь.
Вы получите список всех веток, причем активная будет подсвечена зеленым.
2. Переключитесь в ветку master.
3. Добавьте оригинальный репозиторий в качестве upstream-репозитория.
Чтобы вытащить изменения из оригинального репозитория и перенести их в свою версию, нужно добавить оригинальный git-репозиторий в качестве upstream-репозитория.
4. Fetch репозитория
Заберите (fetch) все изменения из оригинального репозитория. Коммиты, сделанные в оригинальном репозитории, будут сохранены в локальной ветке под названием upstream/master.
5. Слейте изменения
Слейте (merge) изменения из upstream/master с вашей локальной веткой master. Таким образом главная ветка вашего форка репозитория синхронизируется с upstream-репозиторием без потери ваших локальных изменений.
6. Отправьте изменения на GitHub
Примечание. После синхронизации ветки master вашего форка вы можете при желании удалить remote. Но в будущем вам еще придется обновлять/синхронизировать ваш репозиторий, поэтому лучше его сохранить.
8. Удаление ненужной ветки
Ветки создаются с какими-то конкретными целями. Когда цель достигнута, необходимость в ветке отпадает, поэтому ее можно удалить.
Вы можете удалить и версию этой ветки на GitHub.
Итоги
GitHub это мощный инструмент для контроля истории версий. Каждый может стать контрибьютором проекта с открытым исходным кодом. Делается это путем отправки пул-реквестов.
Чтобы стать контрибьютором, не обязательно писать код: есть и другие способы принять участие в проекте.
Наконец, я хотел бы также сказать, что не стоит переживать, если ваши пул-реквесты отклонят. Мейнтейнеры тратят много времени на улучшение своих проектов и они, безусловно, лучше знают эти проекты, чем вы. Поэтому не стоит переживать, если они решат не вливать в свой проект ваши изменения.
Чтобы взяться за работу, нужно определиться с интересами и областью знаний, затем искать проекты. На GitHub непаханое поле задачек разного уровня сложности.
Как только выберете репозиторий, ищем способ начать работу. У вас может быть уверенное понимание того, что нужно изменить в проекте или вы можете намеренно искать проблемные места. Если вы вносите какой-либо вклад, кроме исправления опечатки или проблемы компиляции, прежде чем тратить время на исправление, нужно создать issue в репозитории. Это гарантирует, что работа не будет выполнена впустую и владелец репозитория сможет прокомментировать её реализацию.
Если вы не знаете, над чем хотите работать, перейдите в репозитории во вкладку Issues и просмотрите доступные теги. Вы можете выбрать те проблемы, которые в настоящее время открыты. Для этого в поисковом фильтре, где по умолчанию отображаются is:issue , is:open , добавляем метки label:good-first-issue или label:up-for-grabs (англ. доступный всякому желающему). Или просто нажимаем на такие метки, если заметили их сразу среди issue.
Команда Microsoft тщательно проверяет и комментирует всё, что находится в их беклоге – это облегчит поиск актуальной проблемы.
Далее нужно запостить комментарий о желании работать над этим вопросом. Это важный шаг, так как следует уточнить актуальность целевого вопроса, над которым вы хотите работать.
Репозиторий можно клонировать локально, но вы не сможете сделать pull request без форка. К счастью, этот процесс элементарен – нажмите на кнопку Fork и выполняйте дальнейшие указания GitHub.
В примере в качестве git-клиента использовался GitKraken. Аналогично другим инструментам было проведение клонирование по URL. Вы можете использовать командную строку или другой любимый инструмент.
Следующий шаг зависит от проекта и команды, с которой вы работаете. Нужно выяснить, какую ветку необходимо использовать как базовую. Затем узнать, использует ли команда общие правила именования веток или особые корпоративные правила.
К счастью, об этом не приходится гадать, такие нюансы в большинстве репозиториев описаны в contributing.md или readme.md . Обычно там рассказано, как начать работу с репозиторием, описана структура веток и прочая информация о процессе разработки.
Если таковой документации нет, будьте осторожны, команда может не любить «чужаков».
Прежде чем приступить к работе в редакторе, рекомендуем создать ветку на основе главной ветви. Обязательно проверьте соседние ветки и contributing.md и/или README.md на предмет соглашений об именовании. Имена ветвей не самое важное, так как позже pull request отправляется в другой репозиторий, но это помогает соблюдать порядок.
Итак, теперь, когда у вас есть локальный код, нужно открыть проект в любом редакторе. В рассматриваемом примере в качестве редактора использовался Visual Studio Code.
Следующий шаг – найти подход к структуре проекта. Файл contributing.md поможет разобраться в некоторых директориях. Но не менее полезно изучить структуру вживую: пооткрывать папки и подпапки, пока не поймёте шаблоны организации каталогов и файлов.
Как только войдёте в курс дела, ищите файлы, связанные с кодом, которые собираетесь изменять. В рассматриваемом случае это было легко, так как путь был отмечен в issue:
Как только вы поймете, что находитесь в нужном месте, начинайте делать необходимое исправление, тестируйте и обязательно отправляйте коммит. Собирайте, запускайте тесты и линтеры (если это применимо). Проверка кода – важная часть работы программиста.
К счастью, большинство крупных проектов имеют автоматизированные проверки, встроенные в процесс pull request, что позволит убедиться в сообразности стандартам команды и правильности работы.
После коммита убедитесь, что вы запушили его в форкнутую версию репозитория. Этот шаг необходим для создания pull request.
Делаем pull request форкнутого репозитория по соответствующим подсказкам.
Ветка и репозиторий слева указывают на соответствующие объекты, c которыми вы хотите смержиться. Репозиторий должен быть основным для проекта, а ветка – та, от которой вы клонировались. Справа – форкнутый репозит и его ветка, с которыми вы недавно работали.
Теперь всё готово, следуйте соглашению команды об именовании запроса. В рассматриваемом примере даётся название коммита и в скобках номер issue.
Как только всё готово, нажимаем Create pull request .
Поздравляем, вы внесли небольшой вклад в опенсорсный проект.
Ваш код должен пройти автоматические проверки (чаще всего это билд и анализ кода), прежде чем будет рассмотрен. Кроме того, мейнтейнер проекта разберётся в ваших изменениях и примет решение, внести их в исходный репозиторий или нет.
В нашем примере изменения были оперативно рассмотрены и приняты, о чём GitHub сообщил в уведомлении.
Библиотека программиста настоятельно рекомендует попробовать внести свой вклад в открытое программное обеспечение. Найдите интересный для вас проект и действуйте. Начните с простого проекта, посмотрите как всё работает, а затем беритесь за что-то объёмное. Разработка open source всегда приносит свои плоды, будь то новые навыки, знакомства или просто удовольствие от того, что вы делаете мир лучше.
Читайте также: