Это статья об основах программирования на Go. На канале я рассказываю об опыте перехода в IT с нуля, структурирую информацию и делюсь мнением.
Хой, джедаи и амазонки!
Продолжаю изучать гит, гитхаб и всё что с ними связано. Сделал первый приватный репозиторий, создал пул-реквест для проверки кода и добавил в него ревьюера. Об этом в публикации.
Публикация длинная и будет полезна тем, кто ещё не знаком с созданием pull-request или не знает что это вообще такое. Расписано всё максимально подробно, насколько это возможно для упрощения понимания.
1. Гит
Работаю в Linux, гитом пользуюсь через терминал. Если вдруг вы начали читать эту публикацию, а что такое гит вы не в курсе, вот разъяснение:
Гит - это система контроля версий, которая позволяет разработчикам отслеживать изменения в коде, сотрудничать над проектами и управлять кодовой базой. Например, разработчик может использовать гит для отслеживания изменений в своем коде и слияния их с кодом других разработчиков.
Git позволяет наглядно сравнивать версии программы:
Гитом пользуюсь в связке с гитхабом.
Гитхаб - это веб-платформа для хостинга проектов, управления версиями кода и совместной работы. На гитхабе разработчики могут хранить свой код, отслеживать его изменения, проводить совместную разработку и демонстрировать свои проекты.
Здесь используется термин хостинг. Разберём, что это:
Хостинг проекта означает размещение файлов проекта на сервере, чтобы они были доступны через интернет. Обычно это делается для размещения веб-сайтов, онлайн-приложений или другого контента. Хостинг обеспечивает доступность проекта для пользователей в сети Интернет.
Пример. Технически, после похода в горы с друзьями я заливаю общие фото в облако и делюсь ссылкой на фото - я захостил фотографии. Короче, хостинг = размещение данных в интернете для удалённого доступа к ним.
Возвращаемся к Гиту. Перед тем, как им пользоваться, его нужно настроить и связать с гитхабом, если хотим хостить проекты на этой веб-платформе для совместной работы с командой разработчиком (или хотя бы с вашим проверяющим). Как настроить гит и привязать его к гитхабу не буду рассказывать - в инете достаточно материалов на этот счёт. Перейдём к рабочим вопросам.
Ниже пример работы с гитом из терминала:
Гитом пользуюсь в основном не через терминал OS, а через терминал IDE. Этот и последующие скрины терминала OS просто для удобства примеров.
Минутка (новейшей) истории
---//---//---//---
Git был написан Линусом Торвальдсом (род. 28.12.1969), создателем ядра Linux. Он разработал Git в 2005 году (первая версия выпущена 7 апреля) как ответ на необходимость эффективной системы управления версиями для управления разработкой Linux.
Обстоятельства, которые привели к созданию Git, включают неудовлетворительные результаты использования ранее доступных систем контроля версий для управления интенсивной и распределенной разработкой ядра Linux.
Ещё одна важная фигура в создании и развитии Git - Дзюн Хамано (даты рождения не нашёл, но нашёл его блог).
Хамано начал работать над проектом Git в том же 2005 году в качестве помощника Линуса Торвальдса, и в последующие годы значительно способствовал развитию и совершенствованию Git. Он стал релиз-менеджером проекта, отвечая за подготовку и выпуск новых версий Git, а также принимал активное участие в разработке многих ключевых функций и улучшений в утилите.
Работа Хамано в проекте Git и его вклад в разработку системы контроля версий значительно способствовали успеху и популярности Git в различных областях разработки программного обеспечения.
---//---//---//---
В ходе изучения Go у меня возникла потребность взять существующий код с гитхаба, внести в него изменения и сделать наглядное сравнение двух версий этого кода. Поехали разбираться, как это реализовать.
2. Алгоритм создания pull-request
Pull request или пул-реквест - важная штука в командной работе. Я бы сказал, её краеугольный камень. Не представляю, как без него писались компьютерные игры, операционные системы и другие сложные программные продукты до 2005 года.
Далее расскажу что такое пул-реквест и для чего применяю.
Пул-реквест на GitHub - это запрос на внесение изменений в код проекта и включения этих изменений в основную кодовую базу, который вы предлагаете для обсуждения с более опытным специалистом.
Примеры необходимости пул-реквестов:
- Вы внесли исправления в код проекта и отправили запрос на их включение в основную версию проекта.
- Вы добавили новую функциональность в проект и предложили ее для рассмотрения перед использованием.
- Вы обновили документацию в проекте и хотите, чтобы ваши изменения были просмотрены и приняты.
Другие веб-платформы для хостинга проектов, такие как GitLab, также предоставляют функционал, аналогичный пул-реквестам на GitHub. Например, на GitLab данный процесс называется "Merge Request" (Запрос на слияние).
Термин "пул-реквест" образовался из сочетания английских слов "pull" (тянуть) и "request" (запрос). "Pull" относится к процессу извлечения изменений из другой ветки кода или репозитория, а "request" - к запросу (request) на внесение этих изменений в основную версию проекта.
Репозиторий - это хранилище данных, в котором хранится версионируемая информация, такая как код программ, конфигурационные файлы, документация и другие ресурсы проекта.
В контексте систем управления версиями, таких как Git, репозиторий представляет собой базу данных всех изменений, происходящих в проекте, а также служит для отслеживания и управления версиями файлов.
2.1. Исходные данные
Будем исходить из следующей информации:
- У нас настроен гит, создан аккаунт на гитхаб, связанный с локальным гитом, есть IDE и т.д.
- Есть исходный код: либо это чей-то репозиторий на гитхаб к которому у нас есть доступ, либо этот код наш собственный.
- Нам нужно внести некоторые изменения в исходный код и показать стороннему специалисту внесённые изменения. Но так, чтобы ему было понятно что именно мы изменили по сравнению с исходной версией.
2.2. Получаем исходный код
Есть два варианта получить исходный код.
Первый вариант - исходную версию кода написал ты сам. Если это так, то переходим к пункту 2.3. Если нет - читаем пункт 2.2 целиком, где описываю второй вариант.
Итак, нам нужно скачать исходный код из публичного репозитория. В этом случае два варианта:
- Воспользоваться командой git clone в терминале.
- Скачать zip-архив с кодом из репозитория и не заморачиваться.
2.2-а. Git clone
2.2-a.1. Возьмём для примера игру "Быки и коровы", которую я написал через три недели после начала изучения языка Go. Так выглядит страница по этой ссылке:
2.2-a.2. Нас интересует кнопка Code - она зелёным цветом. Там будет SSH-ключ, который нужно скопировать:
2.2-a.3. Теперь нужно создать папку у себя на компьютере, где будет храниться репозиторий с гитхаба. Можно создать через стандартные инструменты типа "Проводника", можно через терминал:
mkdir consolGames
cd consolGames
Первой строкой создали директорию, второй - перешли в эту новую директорию. Директория consolGames - любое имя для директории, которое вы придумали для хранения репозитория.
2.2.1-a.4. Клонируем через терминал себе содержимое директории:
git clone urlРепозитория
urlРепозитория - SSH-ключ из пункта 2.2.1-a.2. Вот как выглядит пример клонирования удалённого репозитория с гитхаба на локальный компьютер в терминале:
Я ввёл команду git clone - а далее скопированный ssh-ключ с гитхаба.
2.2.1-a.5. На этом всё - наш проект сохранён локально. Проверим через терминал содержимое папки и войдём в склонированную папку:
Файлы на месте. Напомню, ls - команда, которая показывает что находится в директории. О популярных командах терминала я рассказывал в этой публикации.
2.2.1-б. Второй способ скачать репозиторий с гитхаб
2.2.1-б.1. На страничке проекта гитхаб выбираем скачать zip-архив, нажав Download ZIP:
2.2.1-б.2. Архив скачан (обычно в папку "Загрузки") - распаковываем его и перемещаем куда нужно на компьютере. Это можно сделать и через терминал, но пока удобнее более привычными инструментами - через "Проводник".
2.3. Создаём репозиторий на гитхаб
Может возникнуть вопрос - нафига мы скачивали с гитхаба репозиторий, чтобы вновь его туда загрузить?
Исходные данные были - репозиторий чужой. Нам сейчас важно научиться создавать собственный репозиторий и загружать туда локальный код.
2.3.1. Открываем сайт гитхаб. Переходим во вкладку Repositories в своём профиле. Там нажимаем кнопку New - она подсвечена зелёным.
2.3.2. Далее интуитивно понятный интерфейс:
Наша задача придумать имя репозитория и выбрать публичный или приватный - пока всё. В учебных целях выбираем Privat, т.е. приватный. И нажать кнопку Create repository (зелёная внизу справа).
2.3.3. Копируем SSH-ключ в созданном репозитории, область в центре экрана.
В этом пустом репозитории есть подсказки, что делать дальше.
2.4. Загружаем на гитхаб исходный код
2.4.1. Действуем из условия, что в терминале мы находимся в директории с проектом.
Если это по какой-то причине не так, пользуемся командой cd + "имяДиректории" для перехода в папку с проектом. Примерно так может выглядеть переход в директорию с проектом и просмотр содержимого папки:
Если мы клонировали репозиторий через git clone, то подпункты 2.4.2-2.4.5 не требуются. Переходим отсюда к пункту 2.5.
Ещё раз. Далее в подпунктах 2.4 информация для случая, если мы не клонировали репозиторий с гитхаба командой git clone
2.4.2. Инициализируем Git в локальной папке
Вводим git init (команда инициализирует Git в текущей директории):
2.4.3. Создаём ветку программы. Даже если это исходный код - т.е. первичный, - ему нужно присвоить ветку.
Первая ветка в репозитории обычно называется "main" или "master". В терминале набираем команду:
git branch -m main
Команда "git branch -m main" в терминале Git используется для переименования текущей ветки на "main". Опция "-m" является сокращением для "--move" и позволяет переименовать текущую ветку на "main".
2.4.4. Ввести в терминал git add . (добавляем все файлы для "закоммичивания"):
Термин "закоммичивание" в контексте Git означает создание коммита, который представляет собой набор изменений в репозитории.
Коммит - это моментальная фиксация изменений в файловой системе, которая остается в истории репозитория. Когда мы коммитим изменения, Git создает запись о состоянии файлов на момент коммита, включая любые добавленные, измененные или удаленные файлы.
Эти коммиты составляют историю версий проекта и обеспечивают возможность отката к предыдущим состояниям файлов.
Поэтому "закоммичивание" в Git означает сохранение текущего состояния файлов в репозитории с помощью команды git commit.
2.4.5. Ввести в терминал git commit -m "Какое-нибудь сообщение" (создаём коммит. Обычно первый коммит такой "Initial commit"):
2.5. Связываем локальный проект с гитхаб
2.5.1. Копируем SSH-ключ репозитория, заботливо указанный на страничке созданного репозитория. Это действие описано в п.2.3.4.
2.5.2-а. Если мы не клонировали репозиторий, то:
2.5.2-а.1. Выполняем в терминале команду:
git remote add origin <SSH-ключ репозитория>
В терминале я сперва проверил, есть ли связь локального репозитория с удалённым (гитхабом) командой git remote -v. Поскольку терминал ничего не показал, это означает что связи нет. Если по какой-то причине есть связь с удалённым репозиторием, с этого места переходим в п.2.5.2-б.
Затем я создал связь между локальным репозиторием и удалённым (на гитхабе) командой git remote add origin <SSH-ключ репозитория>.
Далее вновь посмотрел, появилась ли связь локального репозитория с удалённым командой git remote -v и выяснил, что появилась.
2.5.2-б. Если мы клонировали репозиторий git clone, то:
2.5.2-б.1. Проверяем, к какому удалённому репозиторию привязка:
git remote -v
Пример действия этой команды см. в п.2.5.2-а.1, т.е. в пункте выше.
2.5.2-б.2. Изменяем url удалённого репозитория командой:
git remote set-url origin <новый_SSH-ключ_репозитория>
Предполагается, что "origin" - это имя удаленного репозитория, к которому проект был привязан. Если было использовано другое имя, нужно заменить "origin" на соответствующее имя удаленного репозитория.
Если мы попробуем назначить удалённый репозиторий локальному репозиторию, у которого уже есть привязка по гит к удалённому репозиторию - то ничего не выйдет. Получим примерно следующую информацию в терминале:
error: внешний репозиторий origin уже существует
2.5.3. Загружаем локальный репозиторий на гитхаб
2.5.3.1. Определяем имя нашей ветки:
git branch
Наименований может быть несколько (см. п.2.7.1). Звёздочкой отмечена текущая ветка.
2.5.3.1. загружаем ветку main (либо другое имя, которое подсказал гит в предыдущем пункте) на гитхаб:
git push -u origin main
2.5.3.2. На гитхаб появляется наша программа (если у вас была открыта страница в браузере, чтобы увидеть изменения, её нужно перезагрузить):
2.6. Вносим изменения локально
Чтобы появилась новая версия проекта (репозитория), нужно работать в другой ветке.
2.6.1. Создаём новую ветку
Для создания новой ветки и переключения на неё вводим в терминал:
git checkout -b название_новой_ветки
Команда создаст новую ветку и автоматически переключит на нее.
2.6.2. Вносим локальные изменения
Далее просто редактируем код. Используем IDE, или любым другим образом.
Я в учебных целях не собираюсь писать большие изменения - просто добавлю несколько строк. Для этого не стану открывать программу в IDE, а воспользуюсь утилитой nano из самого терминала. Запускается она просто:
nano имяРедактируемогоФайла
В результате будет примерно такое отображение:
Сохраняю внесённые изменения, возвращаюсь как-бы в "обычный" терминал, т.е. окно терминала будет тем же, просто исчезнет рабочая область утилиты nano:
2.6.3. Фиксируем изменения в Git
Добавляем все изменения командой:
git add .
2.6.4. Описываем наши изменения в Гите:
git commit -m "Описание ваших изменений"
Описание коммита в команде "git commit -m" принято вносить на английском языке. Обычно описание включает краткое пояснение изменений, внесенных в коммите. Например, "Added welcome message at program start" (Добавлена приветственная речь при запуске программы).
Использование английского языка для описаний коммитов в команде "git commit -m" стало общепринятой практикой, поскольку Git был разработан в англоязычной среде и его сообщества преимущественно используют английский в качестве рабочего языка. Принято считать, что использование английского унифицирует описания коммитов, делая их доступными для всех участников проекта, независимо от их языковых предпочтений. Это также упрощает процессы перевода и взаимодействия в мультиязычных командах и сообществах разработчиков.
2.7. Загрузка ветки на GitHub
2.7.1. Отправляем на гитхаб нашу ветку. Если забыли как она называется - не беда. Воспользуемся командой, о которой говорил в п.2.5.3.1:
git branch
После ввода команды, будет выведен список всех веток проекта. Текущая ветка будет отмечена звездочкой слева от ее названия.
2.7.2. Для отправки ветки на гитхаб используем команду:
git push origin названиеВетки
Готово! На гитхабе появилась новая ветка. Можно выбрать её в списке веток.
2.7.3. Выбираем созданную ветку с внесёнными изменениями
2.8. Создание Pull request
В окне репозитория появилась кнопка Compare & pull request. А давайте не будем на неё нажимать!
2.8.1. Нажмём на кнопку Pull request в панели инструментов:
2.8.2. Здесь нажимаем кнопку New pull request. Появится окно создания пулреквеста. И тут важно выбрать две разные ветки.
Ветка слева - исходная, т.е. наш исходный код - ветка main. Справа - код с предлагаемыми изменениями, который загрузили только что. Выбираем его.
2.8.3. Нажимаем зелёную кнопку Create pull request.
Появляется новое окно. Можем ничего уже не заполнять, нажимаем снова кнопку Create pull request:
2.8.4. На выходе получаем такую картину:
2.8.5. Нажмём на кнопку File changed, как указано на скрине выше. Перейдём во вкладку "сравнение файлов":
Мы видим удобную подсветку и выделение изменённых частей кода. Здесь имеется различный функционал, например добавление вопросов и комментариев. Оставляю это удовольствие исследовать функционал пул-реквеста самостоятельно.
Для нас важно, что мы только что создали пул-реквест. И можем посмотреть и наглядно сравнить две версии программы.
2.9. Делимся ссылкой на pull request с ревьюером
В контексте программирования, ревьюер обычно относится к члену команды разработчиков, который осуществляет код-ревью (code review).
Слово "ревьюер" происходит из английского языка rewewer - рецензент / обозреватель, и обозначает человека, который проводит рассмотрение, оценку и анализ чего-либо, такого как книга, фильм, научная статья и др.
В рамках программирования, ревьюер может осуществлять контроль соответствия кода стандартам языка Go и рекомендациям сообщества, а также помогать в выявлении возможных уязвимостей, повышении производительности и улучшении читаемости кода.
2.9.1-а. Публичный репозиторий
Если репозиторий публичный, а не приватный, просто копируем ссылку из строки поиска браузера и направляем ревьюеру. Тип репозитория выбирали в разделе 2.3.2.
2.9.1-б. Приватный репозиторий
2.9.1-б.1. Заходим в раздел Settings:
2.9.1-б.2. Переходим в раздел Collaborators:
2.9.1-б.3. Сайт попросит ввести пароль:
2.9.1-б.4. Нажимаем кнопку Add people в центре страницы:
2.9.1-б.5. Вводим ник ревьюера с гитхаб:
2.9.1-б.6. Ревьюер должен дать нам адрес своей страницы или ник на гитхаб, чтобы мы могли его добавить. Ник смотрится в профиле страницы:
2.9.1-б.7. Когда добавим ревьюера, копируем ссылку на репозиторий (pull-request) из поисковой строки и делимся ею с ревьюером:
2.9.2. Работа ревьюера
Ревьюер комментирует наш код. Выглядит это примерно так:
2.10. Merge
После внесения изменений, если потребуется - повторного ревью, можем выполнять Merge.
Merge относится к процессу объединения изменений из одной ветки (branch) в другую. В Git это часто используется для объединения ветки разработки с основной веткой, такой как "master" или "main".
Это позволяет разработчикам комбинировать свою работу, проведенную в отдельных ветках, с общим кодовой базой.
На платформе GitHub процесс слияния (merge) также позволяет разработчикам просматривать изменения, вносимые другими членами команды, перед объединением их с основной веткой проекта. Это важная часть коллаборации, поскольку позволяет обеспечить целостность и работоспособность кодовой базы при добавлении новой функциональности или исправлении ошибок.
2.10.1. Нажимаем на кнопку Merge pull request
2.10.2. Далее получаем гитхаб хочет удостовериться, что мы действительно хотим объединить ветку с основной, и, затем, объединяет:
2.10.3. Получаем сообщение "Pull request successfully merged and closed". Можем удалять ветку. Мы молодцы!
3. Выводы
Структурировал распространённую задачу для разработки - создание пулл-реквеста. Пока не написал эту статью и не разложил всё по полочкам, постоянно сталкивался с недопониманием в разных ситуациях, почему так и как действовать.
С пул-реквестами мне помог разобраться друг по видеосвязи. Нас разделяют так-то 6 часовых поясов. Не у всех есть такие друзья. Возможно, для кого-то из вас я стану таким другом, который помогает разобраться в сложных вещах.
Надеюсь эта публикация поможет тебе, юный падаван go-разработки. Успехов тебе. Верь с себя и свои силы, развивай свой ум и своё тело. Будем на связи.
Бро, ты уже здесь? 👉 Подпишись на канал для новичков «Войти в IT» в Telegram, будем изучать IT вместе 👨💻👩💻👨💻
