GitHub: что это и чем отличается от Git

GitHub — веб-сервис для хранения Git-репозиториев и совместной работы над ними. Git при этом остаётся отдельной программой: он записывает историю файлов на вашем компьютере, работает с ветками и умеет обмениваться коммитами с удалённым сервером.

Коротко различие выглядит так: Git хранит и сравнивает версии проекта, GitHub размещает Git-репозиторий в сети и добавляет обсуждение, проверку кода, задачи и автоматизацию.

Что происходит без GitHub

После git init в папке проекта появляется локальный репозиторий. Он содержит файлы, коммиты, ветки и служебные данные. Интернет для создания коммита не нужен.

git init
git status

Команды выполняют в отдельной папке проекта. Первая создаёт каталог .git, вторая показывает состояние. Никакие файлы не отправляются наружу.

Можно месяцами использовать Git локально или разместить удалённую копию на собственном сервере, GitLab, Codeberg и другом совместимом сервисе. GitHub не является обязательной частью Git.

Подробный рабочий цикл команд Git объясняет индекс, commit, branch, pull и push. Здесь сосредоточимся на том, что добавляет платформа GitHub.

Что GitHub добавляет к репозиторию

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

• pull request — предложение объединить изменения одной ветки с другой;
• review — комментарии и решение проверяющего по конкретным строкам;
• Issues — задачи, ошибки и обсуждения, не привязанные к одному изменению;
• Actions — запуск проверок и других автоматизированных процессов;
• Releases — оформленные выпуски с описанием и файлами;
• Projects и Discussions — планирование и более широкие обсуждения.

Git не знает об Issues или pull request. Для него существуют коммиты, ветки, теги и удалённые адреса. Поэтому команда git commit не создаёт pull request, а закрытие Issue само по себе не меняет код.

Как связаны локальная и удалённая копии

Удалённый репозиторий — не сетевой диск, который мгновенно отражает каждое нажатие клавиши. Обмен происходит явными шагами:

1. clone загружает репозиторий с GitHub на компьютер.
2. Вы редактируете файлы и создаёте локальные коммиты.
3. push отправляет новые коммиты в GitHub.
4. fetch получает сведения о новых удалённых коммитах, не меняя рабочие файлы.
5. pull получает изменения и пытается включить их в текущую ветку согласно настройке Git.

Чтобы скачать существующий проект, скопируйте его HTTPS- или SSH-адрес на странице репозитория и выполните:

git clone https://github.com/OWNER/PROJECT.git
cd PROJECT
git status --short --branch

Замените OWNER и PROJECT. Клонирование создаст новый каталог, поэтому запускайте его из родительской папки, где такое имя ещё не занято. Последняя команда должна показать текущую ветку и чистое рабочее дерево.

Адрес GitHub автоматически сохраняется под коротким именем origin. Проверьте его перед первой отправкой:

git remote -v

Команда только читает настройки. Убедитесь, что адрес принадлежит ожидаемому владельцу и репозиторию.

Ветка, clone и fork решают разные задачи

Эти понятия часто смешивают, хотя они относятся к разным уровням.

Ветка — линия разработки внутри репозитория. Она позволяет подготовить изменение отдельно от основной версии.

Clone — полноценная локальная копия репозитория с историей и ссылкой на источник.

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

Обычный участник команды с правом записи создаёт ветку в том же репозитории. Внешний участник открытого проекта чаще делает fork, клонирует его на компьютер, отправляет изменения в свой fork и предлагает pull request в исходный репозиторий.

Fork не синхронизируется с оригиналом магически навсегда. Новые изменения исходного проекта нужно периодически получать и объединять осознанно.

Зачем нужен pull request

Pull request, или PR, не «вытягивает» файлы на ваш компьютер. Он предлагает слить одну ветку в другую и собирает на одной странице всё, что нужно для решения:

• описание цели изменения;
• список коммитов;
• итоговый diff — разницу файлов;
• комментарии и результаты review;
• автоматические проверки;
• состояние возможного слияния.

Простой командный процесс выглядит так:

git switch -c feature/contact-page
# отредактируйте файлы и выполните проверки проекта
git add path/to/changed-file
git commit -m "Add contact page"
git push -u origin feature/contact-page

Выполняйте команды в клонированном проекте. Замените путь к файлу. switch -c создаёт ветку, add готовит выбранный файл, commit фиксирует его локально, а push публикует ветку. После успешной отправки GitHub предложит открыть pull request в браузере.

Не используйте git add ., пока не посмотрели git status: в отправку могут попасть временные файлы, .env и ключи. Перед публикацией полезен отдельный чек-лист проверки Git.

Issues не заменяют документацию и коммиты

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

Коммит хранит фактическое изменение файлов. Pull request объясняет и проверяет набор изменений. Issue хранит исходную проблему и обсуждение. Ссылка между ними помогает восстановить ход решения, но ни один объект не заменяет остальные.

Не публикуйте в Issue журналы целиком без просмотра. Токены, адреса клиентов, внутренние URL и персональные данные могут оказаться в публичном проекте и поисковой выдаче.

Что делает GitHub Actions

Actions запускает сценарии по событиям репозитория: например, после каждого push выполняет тесты или собирает сайт. Сценарий хранится в YAML-файле внутри .github/workflows/, а выполнение происходит на runner — машине, предоставленной GitHub или подключённой владельцем.

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

GitHub Actions — не обязательная часть первого репозитория. Сначала добейтесь воспроизводимой локальной проверки, затем переносите уже понятную команду в CI.

Публичный и приватный репозиторий

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

Ни один режим не разрешает коммитить секреты. Пароль может сохраниться в старом коммите даже после удаления из текущего файла, попасть в fork, clone, журнал сборки или кеш. Для автоматизации используйте GitHub Secrets, а локальные .env исключайте через .gitignore. Если секрет уже опубликован, сначала отзовите или замените его; простого удаления файла недостаточно.

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

Когда GitHub полезен, а когда избыточен

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

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

Источники

• GitHub Docs: что такое GitHub
• GitHub Docs: Hello World и первый pull request
• GitHub Docs: о pull requests
• Git: официальная документация