Что такое GitHub и как им пользоваться

83 миллиона пользователей, четыре миллиона организаций и 200 миллионов репозиториев. В Сети много сервисов для размещения исходного кода своих проектов, но говорят чаще всего именно про GitHub. В чём же дело?

Конечно, известный владелец сервиса (Microsoft) и привычка играют свою роль, но главная причина — возможности платформы.

Что такое GitHub и чем он отличается от Git

GitHub — это облачная платформа для хостинга IT-проектов и совместной разработки, под капотом которой находится популярная система контроля версий Git, а также полноценная социальная сеть для разработчиков.

Здесь можно найти кучу open-source-проектов на разных языках и поучаствовать в них, разместить своё портфолио с примерами кода, чтобы приложить ссылку к резюме, подглядывать в открытых проектах интересные архитектурные решения, смотреть, как опытные разработчики пишут код, и скачивать огромное количество полезных в разработке и бесплатных инструментов для разработки. Кстати, некоторые умельцы умудряются собирать в GitHub целые библиотеки — книг и статей, а не программистские либы :)

И да, если вы недовольны какими-то фичами в любимой открытой программе и она выложена на GitHub, вы всегда можете прийти и поругаться в комментариях к проекту :) А лучше всего — оформить issue (мы расскажем, что это) и самостоятельно пофиксить проблему на радость всем пользователям. Не забывайте и благодарить авторов классных открытых проектов — донатами и просто тёплыми словами. Им будет очень приятно.

Придя практически в любую IT-компанию, вы столкнётесь с тем, что код где-то хранится — и в подавляющем большинстве случаев этим «где-то» будет именно GitHub. У GitHub есть довольно известный конкурент — GitLab, он тоже основан на Git, но это разные платформы разных компаний, хотя их функциональность очень похожа.

Ну как, звучит круто? Тогда приступайте к нашему гайду о том, как пользоваться GitHub, чтобы во всём разобраться и вообще понять, нужен ли он вам прямо сейчас.

Как понять, нужен ли вам GitHub

Безусловно, GitHub нужен не всем. Допустим, вы ещё только учитесь кодить или неспешно делаете небольшой проект для личного пользования — и вас устраивает хранение проекта на локальной машине. Может, сейчас вы просто учите язык, который вам нравится, и на данном этапе не хотите хвататься за всё сразу.

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

И действительно, есть множество других способов хранения исходников: можно создать для них папку в разделе «Мои документы», закидывать их в облако и подписывать версии или даже загружать в «Избранное» в Telegram или «ВКонтакте» (костыльно, да, но вполне реально).

А ещё можно накидывать список изменений в заметках в телефоне/на холодильнике текстом в приватном Telegram-канале. Можно деплоить проект с помощью простого скачивания и распаковки ZIP-архива с файлами вашей программы (особенно если цель — просто показать программу другу или девушке, которой вы пришли «помочь с ноутбуком» ^_^). В конце концов, можно сообщать о багах в вашем любимом фреймворке сообществу анонимов в паблике в VK — возмущаться вместе очень весело.

Все эти способы по-своему хороши, но для работы в IT нужно привыкать к GitHub: это стандарт индустрии.

Большая часть необходимых возможностей GitHub бесплатна, хотя у платформы есть и платные тарифы — однако с ними можно долго не сталкиваться, потому что бесплатных обычному разработчику хватает с лихвой.

Основные концепции GitHub простыми словами

Новичков интерфейс GitHub может сбивать с толку: за годы с момента создания площадка обросла множеством инструментов, но главное остаётся неизменным.

Почти вся терминология наследуется у Git. Основные термины — репозиторий, ветка, коммит, форк. Выбор некоторых из этих названий может показаться не очень интуитивным (даже если вы владеете английским), но так уж сложилось.

Репозиторий

Это просто корневая папка с файлами и вложенными директориями вашей программы — и одновременно её страница на GitHub. Загрузить в репозиторий можно всё что угодно, но предполагается, что вы будете хранить в нём файлы с исходным кодом и какие-нибудь дополнительные материалы — допустим, необходимую для GUI или вёрстки графику (картинки, иконки и тому подобное).

Репозитории могут быть публичными и приватными, в них можно создавать другие папки и отслеживать изменения версий. Управлять своими репозиториями можно прямо через интерфейс сайта, командную строку, десктопное приложение GitHub или различные средства разработки (IDE), поддерживающие интеграцию с сервисом.

Читайте также:

GitHub Desktop и плагины для редакторов кода и IDE: VS Code, PyCharm, Eclipse и других

Ветка (branch)

В ветки группируются изменения и обновления — допустим, одна главная ветка (по умолчанию создаётся main) и одна beta. Ветки независимы друг от друга, но при желании их можно объединять (merge — слияние) — даже если между ними есть разница в коде.

Способы изменения репозитория: коммит, пуш, клон, форк

Внести в содержимое репозитория изменения можно напрямую или создав копию. Само внесение изменений называется «коммит» (от английского commit — совершить), у него есть временная метка и хеш-сумма.

Перенос изменений-коммитов из локального репозитория (на вашем ПК) на удалённый (remote repository, то есть в данном случае на GitHub) называется «пуш» (push) — от английского «толкать» (дословно — «проталкивать» изменения).

Скопировать репозиторий для внесения изменений в копию можно двумя основными способами:

• клонировать (clone) — то есть просто скопировать на локальный компьютер или сервер;
• или форкнуть (от английского fork — развилка) — сделать отдельную копию репозитория (обычно чужого) для продолжения разработки «по другому пути развилки».

Если вы форкнули чужой проект, чтобы предложить автору конкретные улучшения, нужно по готовности «запулить» их в исходный репозиторий — то есть сделав pull request (запрос на изменения).

Это 90% необходимых фактов. Более скучные подробности описаны в документации и разделе обучения GitHub, а также в руководстве по самому Git, ну а мы попробуем применить всё это на практике.

Создание репозитория и загрузка файлов

Конечно, самый простой способ пользоваться GitHub — через сайт, поэтому начнём отсюда.

Самые типичные действия при работе с репозиторием — его создание и загрузка файлов, их мы уже рассматривали ранее. Легко убедиться, что обе задачи занимают не больше 30 секунд.

Очень кратко повторим выводы из нашего прошлого материала:

• для создания репозитория нужно нажать на + в правом верхнем углу сайта, выбрать пункт New Repository, заполнить название и описание, проставить нужные галочки и щёлкнуть на Create Repository;
• для загрузки файлов нужно зайти в нужный репозиторий, щёлкнуть на Add file и выбрать Upload files.

Но для обучения Тёмной стороне Силы работе с GitHub полезно потренироваться выполнять и другие необходимые в процессе разработки действия: клонирование/форк, объединение веток, просмотр и разрешение конфликтов и другие.

Давайте пошагово пройдём всё это вместе — сначала через сайт, а потом взглянем одним глазком на работу через GUI-клиенты и интерфейс командной строки (CLI).

Просмотр файлов в репозитории

Согласитесь, что в ряде случаев удобно не скачивать исходники, а просто бегло ознакомиться с ними. Для таких простых операций вовсе не нужен десктопный клиент: все файлы можно быстро открыть в веб-версии (и код, и те же картинки). Просто щёлкните по ним для просмотра!

Поиск и чтение репозиториев

Хотя сёрфинг по чужим репозиториям — залипательное времяпровождение, в первую очередь это один из способов нахождения полезных инструментов вам в помощь. Над многими функциями, которые вы хотели бы добавить в своё приложение, уже кто-то работал, остаётся только найти GitHub-репозитории таких проектов.

Как и в других случаях поиска, вы можете выйти на нужный репозиторий из поисковика или через внутренний поиск по GitHub.

Важнее другое — на что обращать внимание. Пройдёмся по некоторым пунктам со скриншота выше.

Во-первых, самое очевидное — это описание на главной странице. Именно в нём находится ответ на ваш главный вопрос — что это и чем может вам помочь.

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

После этого оцените, подходит ли вам частота обновлений, — это можно сделать в разделе Releases (ссылка прямо под кратким описанием). Конечно, это зависит от ситуации: где-то может пригодиться инструмент, который не обновлялся четыре года, но чаще всего нужна хотя бы минимальная поддержка — то есть обновления минимум раз в несколько месяцев.

Важно знать и где посмотреть количество и содержание коммитов — кликабельный счётчик находится над списком файлов справа.

Наконец, стоит взглянуть и на количество отметок, демонстрирующих популярность проекта среди сообщества, — отслеживаний, форков и звёздочек (это в каком-то смысле местные аналоги лайков и репостов).

Ещё чуть ниже справа — одна из самых интересных штук: анализ используемых в репозитории языков программирования. В репозитории со скриншота выше набор выглядит так.

Вообще, неплохо изучать репозитории известных приложений, которыми сами пользуетесь (как на скриншоте выше), и отмечать понравившиеся звёздочками. Это не только интересно — со временем GitHub изучит ваши предпочтения и станет предлагать в блоке Explore то, что вам может понравиться.

Создание веток

Создать новую ветку очень просто:

• Жмём на большую зелёную кнопку New branch.
• Вводим название новой ветки.
• Выбираем исходную ветку для копирования (то есть main, так как пока других и нет).
• Щёлкаем на Create branch.

Переключение веток и решение конфликтов

В данном случае нужно сначала уточнить, что имеется в виду: если необходимо просто зайти в альтернативную ветку, это можно сделать в списке веток репозитория (нужная ссылка есть над списком файлов).

Создадим также альтернативную ветку №2 (sava) и посмотрим, как всё это выглядит в итоге.

Можно говорить и про переключение между ветками в другом смысле — когда изменения из альтернативной ветки сливают с главной веткой. Смотрите: у нас есть файл code.js, но его содержимое немного отличается:

• в ветке main там JS-команда console.log («Дефолтная ветка») и картинка с великим маэстро современности Риком Эстли;
• однако в ветке koshka тот же файл содержит команду console.log («Кошка!»);, а вместо Рика — смешной кот;
• и всё совсем усложняется третьей веткой sava, где консольный вывод вида console.log («Сова!»); и используется картинка с совой (естественно, все перечисленные картинки во всех ветках называются одинаково — pic.jpg).

Получается, между ветками есть конфликт и просто слить любую из альтернативных веток с главной нельзя! Но для этого уже есть решение: GitHub предлагает нам сравнить конфликтующие ветки, и если мы захотим, то и запулить изменения в основную — то есть сделать тот самый pull request, о котором говорилось выше.

Вот как выглядит сравнение веток (c koshka и sava соответственно).

Допустим, мы решаем принять изменения из ветки sava и создаём pull request с небольшим комментарием.

Дальше он появляется в списке пул-реквестов репозитория, где мы определяем дальнейшую судьбу данного запроса на изменения.

Пул-реквест можно окончательно принять, подтвердив слияние (merge) веток, или отклонить, закрыв запрос (Close pull request).

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

Чтобы поменять данный ряд параметров, зайдите в своём репозитории в раздел Settings -> Branches. Нужные настройки — в подразделе Branch protection rules (целых 10 галочек на выбор).

Настройка описания репозитория

Основное описание вашего GitHub-проекта задаётся в файле Readme.md, который можно создать вместе с репозиторием или после. Расширение md — это просто сокращение от названия популярного языка упрощённой разметки контента — Markdown.

Содержимое файла Readme отображается на главной странице репозитория и отвечает на вопрос, что это за проект, чем он может быть полезен другим разработчикам и как им воспользоваться.

Чтобы оформить Readme со вкусом, можно воспользоваться руководством GitHub по markdown-разметке. Вот как будет выглядеть Readme нашего репозитория-примера после прокачки (первый и второй экран соответственно).

Обратите внимание: в оформлении можно использовать всё что угодно — заголовки разных уровней, выделение жирным/курсивом, изображения, эмодзи, ссылки и так далее.

Файл Readme может быть довольно длинным, но всё же для оформления большой документации GitHub рекомендует создать «Вики».

Создание сайта из вашего GitHub‑профиля

Захостить сайт на GitHub можно с помощью функции GitHub Pages. Это очень просто:

• Зайдите в настройки репозитория.
• В блоке Code and automation выберите Pages.
• Выберите источник (Deploy from a branch, затем нужную ветку).
• Кликните на Save.
• Обновите страницу, и вверху страницы появится ссылка на ваш новый сайт.

В случае создания сайта для продвижения себя, а не проекта, просто создайте репозиторий с кодом сайта-визитки и дайте ему имя вида [username].github.io, где username — название вашего аккаунта на GitHub. Более подробно про эту функцию — тут.

Подключение GUI-клиента GitHub Desktop

Если вам удобнее такой способ работы, здесь всё тоже просто. Опять же, повторим кратко выводы из нашего более подробного гайда на эту тему:

• Скачиваем и устанавливаем сам клиент.
• Авторизуемся в своей учётной записи.
• Работаем с существующими репозиториями или создаём новые (локальные).

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

Клонированные из удалённого GitHub-репозитория файлы хранятся в специальной папке на вашем компьютере, и в них легко вносить изменения — клиент будет открывать их в выбранном вами редакторе кода / среде разработки (хотя удобнее всё по отдельности — выбрав нужный файл-исходник в папке).

В общем, всё просто, как раз-два-три.

Работа с GitHub через CLI

Работать с GitHub можно и через командную строку Windows или PowerShell. Это не очень сложно: для начала интерфейс командной строки также нужно скачать и установить (документация — здесь).

Команды для GitHub CLI начинаются с сокращения gh — к примеру gh repo clone.

Есть и другой вариант — использовать собственно Git и работать через его собственный CLI. Git скачивается и устанавливается отдельно, там есть минималистичный GUI, но его уже логичнее использовать в терминале.

Главное, что нужно про это знать: все команды Git начинаются соответственно — со слова git, после чего указывается тип действия: git clone, git merge, git fork и прочее. Чтобы воспользоваться ими, установите Git, распечатайте себе любую памятку по его командам и смело начинайте ими пользоваться.

Настройка GitHub-профиля

Кастомизация профиля — важная часть самопрезентации разработчика: резюме, визитная карточка и витрина проектов, над которыми вы работали.

Эту информацию оценивают работодатели, поэтому стоит заполнить информацию о себе и сделать публичными несколько ваших лучших репозиториев (конечно, если там ничего секретного :)) — именно они будут частью вашей персональной витрины.

Посмотрим на профиль какого-нибудь крутого разработчика из тех, кто сейчас в тренде GitHub (да-да, есть и такой раздел).

На первом месте — некий Стивен Селис. А что в его профиле? Указано место работы, есть сайты и контакты, а в статистике — 123 репозитория и 1725 изменений в репозиториях за год (круглый год). То есть невооружённым глазом видно, что человек как минимум активный и опытный.

Даже если вы пока ещё не в топе GitHub, нужно стремиться к подобному наполнению профиля: подробная информация + показательный ряд проектов (вы можете закреплять их по-своему, нажав в собственном профиле на Customize your pins).

Вместо end()

Всё не так сложно, как может показаться (говоря иносказательно, каждый разработчик в своей жизни сначала учится есть вилкой, а потом — форкать GitHub-репозитории).

GitHub пользуются все: это один из важных общих навыков вне зависимости от выбранного вами языка программирования и направления разработки. И, как и школьные уроки ОБЖ, тот же git clone когда-нибудь вас спасёт.

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