41. Рабочий процесс с открытым исходным кодом
Содержание
Рабочий процесс с открытым исходным кодом
Когда мы изучали основы GitHub, мы проходили процесс форка произвольного проекта и внесения изменений в наш локальный репозиторий. Здесь мы хотим сделать еще один шаг вперед и внести свой вклад в проект с открытым исходным кодом. Помните, что вклад не обязательно должен заключаться в исправлении ошибок, кодировании функций, это может быть и документация. Каждая мелочь помогает, и это также позволит вам поработать с некоторыми функциями git, которые мы рассмотрели.
Форк проекта
Первое, что нам нужно сделать, это найти проект, в который мы можем внести свой вклад. Я недавно выступал с презентациями в Kanister Project и хотел бы поделиться своими презентациями, которые теперь есть на YouTube, с основным readme.mdf-файлом проекта.
Прежде всего, нам нужно форкнуть проект. Давайте проделаем этот процесс. Я собираюсь перейти по ссылке, указанной выше, и форкнуть репозиторий.
Теперь у нас есть наша копия всего репозитория.
Для справки в файле Readme.mdfile в списке оригинальных Presenations указаны только эти два, поэтому нам нужно исправить это в нашем процессе.
Клонирование на локальную машину
Теперь у нас есть собственный форк, который мы можем перенести на локальную машину и начать вносить правки в файлы. Используя кнопку code на нашем репозитории, мы можем получить URL, а затем использовать git clone url в каталоге, куда мы хотим поместить репозиторий.
Вносим изменения
У нас есть локальный проект, поэтому мы можем открыть VSCode или IDE или текстовый редактор по вашему выбору, чтобы добавить свои изменения.
Файл readme.mdfile написан на языке markdown, и поскольку я изменяю чужой проект, я собираюсь следовать существующему форматированию проекта для добавления нашего содержимого.
Тестируем свои изменения
В качестве лучшей практики мы должны тестировать наши изменения, это совершенно логично, если бы это было изменение кода приложения, вы бы хотели убедиться, что приложение продолжает функционировать после изменения кода, но мы также должны убедиться, что документация отформатирована и выглядит правильно.
В VScode у нас есть возможность добавить множество плагинов, одним из которых является возможность предварительного просмотра страниц в формате markdown.
Верните изменения в наш форкнутый репозиторий
У нас нет аутентификации, чтобы отправить наши изменения непосредственно в репозиторий Kanister, поэтому мы должны пойти этим путем. Теперь, когда я доволен нашими изменениями, мы можем выполнить некоторые из этих хорошо известных команд git.
Теперь мы возвращаемся в GitHub, чтобы еще раз проверить изменения и затем внести вклад в мастер-проект.
Теперь мы можем вернуться в верхнюю часть нашего форкнутого репозитория для Kanister и увидеть, что мы на 1 коммит опережаем ветку kanisterio:master.
Далее мы нажимаем на кнопку “Внести вклад”, выделенную выше. Мы видим опцию “Open Pull Request”.
Open a pull request
На следующем изображении происходит довольно много всего: слева вверху вы видите, что мы находимся в оригинальном или основном репозитории. Затем вы можете увидеть, что мы сравниваем, а это оригинальный основной и наш форкнутый репозиторий. Затем у нас есть кнопка создания запроса на притяжение, к которой мы скоро вернёмся. У нас есть единственный коммит, но если бы изменений было больше, то здесь могло бы быть несколько коммитов. Затем у нас есть изменения, которые мы внесли в readme.mdfile.
Мы просмотрели вышеуказанные изменения и готовы создать pull request, нажав на зеленую кнопку.
Затем, в зависимости от того, как мейнтейнер проекта настроил функциональность Pull Request в своём репозитории, у вас может быть или не быть шаблона, который даст вам указания на то, что хочет видеть мейнтейнер.
Здесь вам снова нужно составить содержательное описание того, что вы сделали, четкое и краткое, но достаточно подробное. Вы можете видеть, что я сделал простой обзор изменений и отметил документацию.
Создайте запрос на исправление
Теперь мы готовы к созданию запроса на исправление. После нажатия кнопки “Create Pull Request” в верхней части страницы вы получите краткое описание вашего запроса.
Прокручивая страницу вниз, вы, вероятно, увидите, что происходит автоматизация, в данном случае нам требуется рецензия, и происходят некоторые проверки. Мы видим, что Travis CI находится в процессе и началась сборка, которая проверит наше обновление и убедится, что перед тем, как что-то будет слито, мы не сломаем что-то своими добавлениями.
Еще одна вещь, которую следует отметить, это то, что красный цвет на снимке экрана выше, может выглядеть немного пугающе и выглядеть так, как будто вы совершили ошибки! Не волнуйтесь, вы ничего не нарушили, мой главный совет - этот процесс поможет вам и сопровождающим проекта. Если вы допустили ошибку, по крайней мере, по моему опыту, сопровождающий свяжется с вами и посоветует, что делать дальше.
Этот запрос на исправление теперь общедоступен для всех added Kanister presentation/resource #1237.
Я собираюсь опубликовать это до того, как слияние и запрос на исправление будут приняты, так что, возможно, мы сможем получить небольшой приз для тех, кто всё ещё следит за развитием событий и сможет добавить картинку к успешному PR?
- Форкните этот репозиторий на свой собственный аккаунт GitHub
- Добавьте свою картинку и, возможно, текст
- Внесите изменения в свой форкнутый репозиторий.
- Создайте PR, который я увижу и одобрю.
- Я придумаю какой-нибудь приз.
На этом мы завершаем знакомство с Git и GitHub, далее мы погружаемся в контейнеры, что начинается с рассмотрения общей картины того, как, почему контейнеры, а также с рассмотрения виртуализации и того, как мы к ней пришли.