Подключить учебный проект к GitHub

До этого урока вся работа с remote-репозиторием шла внутри учебного окружения: локальный bare-репозиторий remote/shared.git играл роль «сервера». Теперь подключаем настоящий облачный remote — GitHub. Принцип тот же: Git отправляет коммиты по адресу, зарегистрированному в .git/config. Меняется только адрес и то, как Git аутентифицируется на другом конце.

GitHub-аккаунт и бесплатный план

GitHub — это облачный хостинг Git-репозиториев. С точки зрения Git он ничем принципиально не отличается от локального bare-репозитория: хранит объекты и принимает push. Разница в том, что репозиторий доступен по сети, у него есть веб-интерфейс, и доступ к нему контролируется аккаунтом.

Бесплатный план (Free) позволяет создавать сколько угодно публичных и приватных репозиториев для личного использования. Для этого урока никаких платных функций не нужно.

Чтобы начать работу, достаточно зарегистрироваться на github.com и подтвердить e-mail. После подтверждения аккаунт полностью функционален.

Важный момент про курс в целом: все предыдущие уроки и основная локальная практика работают без GitHub-аккаунта. Этот урок — отдельный облачный блок. Если аккаунта пока нет, локальная работа продолжается независимо.

Безопасная HTTPS-авторизация: GCM и GitHub CLI против токена в URL

При работе с GitHub по HTTPS важно понять одну вещь сразу: пароль от аккаунта GitHub не является учётными данными для Git. GitHub требует либо токен (Personal Access Token), либо OAuth-авторизацию через браузер. Вводить пароль от веб-сайта в командную строку Git не получится — он не сработает.

Есть два рекомендованных способа авторизовать Git для работы с GitHub.

Git Credential Manager (GCM) входит в современный Git for Windows. Основной путь этого опыта на Windows — установленный Git for Windows с включённым GCM: при первом HTTPS-доступе он предлагает вход через браузер. Войдите в свой аккаунт GitHub, подтвердите разрешение OAuth-приложения и пройдите 2FA, если она запрошена. После успешной авторизации стандартный GCM сохраняет данные в Windows Credential Manager, вне проекта. Если ожидаемого входа через GCM нет и терминал просит обычный пароль, не подставляйте пароль сайта или токен в URL: сначала проверьте установку GCM.

На macOS и Linux установка и настройка хранилища отличаются; подготовьте их по официальной инструкции GitHub для вашей ОС до публикации.

GitHub CLI — альтернативная отдельная утилита. После её установки команда gh auth login запускает интерактивную настройку. Выберите GitHub.com, протокол HTTPS, ответьте Y на предложение авторизовать Git и выберите вход через браузер; подтвердите показанный одноразовый код и необходимые разрешения на GitHub. Именно выбор HTTPS и согласие на Git-авторизацию настраивают этот путь для Git. Один факт запуска login не гарантирует эти настройки или отсутствие будущих запросов.

CLI обычно использует защищённое системное хранилище, но при его недоступности может сохранить токен в обычном текстовом файле. Команда gh auth status показывает состояние входа и место хранения; не выводите и не копируйте сам токен. Если обнаружен такой fallback, не считайте его защищённым хранилищем: сначала настройте доступный credential store либо используйте подготовленный GCM. Не выбирайте хранение в открытом виде. Эта граница описана в официальном manual gh auth login.

---

Есть распространённый способ, который выглядит удобным, но создаёт проблему безопасности: вставить токен прямо в URL remote-а.

# Так делать нельзя
git remote add github https://ghp_ВашТокен@github.com/username/repo.git

После выполнения этой команды токен сохраняется в .git/config в открытом виде:

[remote "github"]
    url = https://ghp_ВашТокен@github.com/username/repo.git
    fetch = +refs/heads/*:refs/remotes/github/*

Любой, кто откроет этот файл, увидит токен. Если .git/config случайно окажется в архиве, будет отправлен по почте или если токен попадёт в историю коммитов — он становится доступен посторонним.

Аналогичная проблема возникает, если сохранить токен в файле внутри рабочей папки (например, token.txt), особенно если файл не добавлен в .gitignore. Даже с .gitignore такой файл остаётся на диске и в папке проекта.

Учётные данные должны храниться вне проекта в проверенном защищённом хранилище выбранного инструмента. Не сохраняйте их в URL или файлах проекта; сам выбор CLI ещё не подтверждает защищённое хранение.

Создание пустого репозитория на GitHub и регистрация remote

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

Создание репозитория через веб-интерфейс:

1. Войдите в аккаунт на github.com.
2. Нажмите «+» в правом верхнем углу → «New repository».
3. Введите имя репозитория, например my-project.
4. Выберите Public или Private — для учебных целей оба варианта подходят.
5. Не ставьте галочку «Add a README file». Также не выбирайте .gitignore и лицензию.
6. Нажмите «Create repository».

Почему важно не добавлять README: если GitHub создаёт репозиторий с файлом README, он автоматически делает начальный коммит. У этого коммита нет связи с вашей локальной историей. Когда вы попытаетесь отправить свои коммиты, Git откажет в push с сообщением об ошибке — remote содержит историю, которой нет у вас локально (non-fast-forward). Пустой репозиторий без единого коммита этой проблемы не создаёт.

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

---

Копирование HTTPS URL:

На странице репозитория найдите раздел «Quick setup» или кнопку «Code» → убедитесь, что выбрана вкладка HTTPS, не SSH. URL выглядит так:

https://github.com/username/my-project.git

Скопируйте его целиком — он понадобится в следующей команде.

---

Регистрация remote командой git remote add:

Для локальной части распакуйте весь git_practice.zip в новую пустую папку. Откройте терминал в её git_practice либо выполните cd "полный путь к новой папке/git_practice" со своим путём. Папки my_github_demo ещё нет; создайте её клонированием:

git clone remote/shared.git my_github_demo
cd my_github_demo
git config user.name "Student"
git config user.email "student@example.com"
git status
git log --oneline

Должны быть чистая main и один исходный коммит с README: заголовок «# Командный справочник», контакт «команда», статус «черновик». Не создавайте здесь новых коммитов. Обе настройки автора локальные и нужны для будущей работы; они не меняют автора уже имеющегося коммита. git init не нужен.

В этом клоне зарегистрируйте именно HTTPS URL своего нового пустого GitHub-репозитория. В следующей строке замените username/my-project своими значениями:

git remote add github https://github.com/username/my-project.git

Что происходит: Git записывает имя github и соответствующий URL в файл .git/config. Файлы проекта не изменяются, коммиты никуда не отправляются. Команда просто регистрирует адрес.

Проверьте результат:

git remote -v

Вывод будет примерно таким; путь origin может быть абсолютным путём к новой распаковке:

github  https://github.com/username/my-project.git (fetch)
github  https://github.com/username/my-project.git (push)
origin  ../remote/shared.git (fetch)
origin  ../remote/shared.git (push)

Видны два remote: origin (учебный bare-репозиторий из архива) и github (только что зарегистрированный). Они сосуществуют в .git/config и не конфликтуют. Команды, адресованные конкретному remote, всегда получают его имя явно: git push github main отправляет на GitHub, git push origin main — в локальный bare. Git не путает их между собой.

Первый push на GitHub и проверка коммитов в веб-интерфейсе

После регистрации remote можно отправить коммиты:

git push -u github main

Вся команда отправляет ветку main на remote github; флаг -u (сокращение от --set-upstream) дополнительно запоминает upstream для успешно отправленной ветки. После этого в том же репозитории достаточно вводить git push без аргументов — Git уже знает, куда отправлять изменения из main.

При выбранном пути через подготовленный GCM первое обращение к GitHub может открыть браузер для входа и подтверждения разрешений. Если вы уже авторизовались через правильно настроенный CLI или GCM, новый запрос может не потребоваться. После успешной авторизации и разрешённого доступа команда отправляет коммиты; ориентируйтесь на фактический результат push.

Вывод при успешной отправке содержит строку:

To https://github.com/username/my-project.git
 * [new branch]  main -> main

[new branch] означает, что ветка main впервые появилась на этом remote. Это нормально для первого push в пустой репозиторий.

---

Проверка через веб-интерфейс:

Откройте страницу репозитория на github.com. На вкладке «Code» должны быть видны файлы проекта — так же, как в рабочей папке локально.

Рядом с именем ветки есть ссылка «N commits». Кликните на неё — откроется список коммитов. Сравните сокращённые ID и заголовки сообщений с локальным выводом:

git log --oneline

git log --oneline не выводит автора. Для его проверки откройте нужный коммит на GitHub и локально просмотрите тот же коммит известной командой git show <ID>; для верхнего коммита можно выполнить git show HEAD. Сравните поле Author, сообщение и diff. Автор исходного учебного коммита сохраняется при push; настройка Student сама его не меняет. Успешный push, правильная ветка main, совпадающие ID и содержимое README подтверждают публикацию.