Как пользоваться GitHub новичку: репозиторий, коммит, ветка и возврат к рабочей версии

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

Для первого маршрута достаточно понять четыре объекта: репозиторий, коммит, ветку и pull request. Пятый навык - безопасно отменить неудачное изменение.

Репозиторий содержит файлы и снимки их изменений. На GitHub он может быть публичным или приватным. Публичный репозиторий виден всем, поэтому никогда не загружайте туда пароли, API-ключи, клиентские данные и внутренние документы.

Создавая первый репозиторий на сайте GitHub, укажите понятное имя и описание. Для учебного проекта можно сразу добавить README.md. В нем напишите:

· что делает проект;

· как его запустить;

· какие зависимости нужны;

· какие переменные окружения ожидаются, но без секретных значений;

· кто отвечает за проект.

Файл .gitignore указывает, какие локальные файлы Git не должен предлагать для коммита. Обычно туда входят зависимости, сборка, временные файлы и .env. Но .gitignore не удаляет секрет из истории, если файл уже был закоммичен.

Проект на GitHub находится удаленно. Чтобы работать с ним на компьютере, создайте локальную копию командой git clone или через GitHub Desktop.

В терминале:

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

Перед работой выполните:

Команда показывает текущую ветку, измененные и новые файлы. Привыкайте запускать ее до и после любой задачи, особенно если код меняет ИИ-агент.

Коммит сохраняет выбранные изменения в истории. Он не отправляется на GitHub автоматически. Типичный цикл:

Здесь четыре разные проверки:

· git status показывает состав изменений;

· git diff показывает еще не подготовленные строки;

· git add выбирает точные файлы для следующего снимка;

· git diff --cached показывает, что попадет в коммит.

Не используйте git add . по привычке, пока не просмотрели новые файлы. Так в историю попадают .env, большие выгрузки, скриншоты и результаты сборки.

Хороший коммит отвечает на вопрос «что изменилось». Сообщение fix почти ничего не объясняет. Сообщение Prevent duplicate booking submission помогает найти решение позже.

Ветка позволяет делать работу отдельно от стабильной версии. Основная ветка часто называется main. Для новой функции создайте ветку:

Теперь коммиты попадут в новую ветку. Это не копия всей папки вручную, а отдельный указатель в истории Git.

Название должно описывать задачу: fix/mobile-menu, docs/setup, feature/user-profile. Не храните десятки несвязанных изменений в одной ветке. Чем уже задача, тем проще проверить diff и вернуть только плохую часть.

После первого коммита отправьте ветку:

Флаг -u связывает локальную и удаленную ветки. Следующие отправки можно делать обычным git push.

На GitHub откройте pull request из рабочей ветки в main. В описании укажите:

· какую проблему решает изменение;

· что именно сделано;

· как проверить результат;

· какие ограничения остались;

· есть ли скриншоты или миграции данных.

Pull request нужен не только большой команде. Даже в личном проекте он создает паузу между «код написан» и «код стал основной версией». В этой паузе можно прочитать diff, запустить проверки и заметить лишний файл.

После одобрения ветку объединяют. GitHub сохраняет обсуждение и связь между коммитами. Удаление рабочей ветки после merge не удаляет вошедшие изменения.

Перед новой работой обновите локальную основную ветку:

git pull получает изменения и объединяет их с текущей веткой. Официальная документация GitHub советует сначала сохранить локальную работу, потому что при пересечении строк может возникнуть конфликт.

Более осторожный маршрут:

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

Способ зависит от того, где находится ошибка.

Сначала прочитайте diff. Если нужно отбросить изменения конкретного файла:

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

Уберите его из staging, сохранив рабочую правку:

После этого исправьте файл или исключите его из коммита.

Для общей ветки безопаснее создать новый коммит, который отменяет старый:

revert не переписывает опубликованную историю. Он добавляет явную обратную операцию. Это удобнее для команды, чем принудительная отправка переписанной ветки.

Если не уверены, остановитесь и создайте резервную ветку. Не используйте reset --hard из случайного совета: команда может безвозвратно убрать локальные изменения.

Конфликт возникает, когда Git не может автоматически объединить правки в одном участке. В файле появятся маркеры двух версий. Нужно выбрать правильный итоговый текст, удалить маркеры, проверить приложение и создать коммит объединения.

Не просите ИИ «решить все конфликты» без контекста. Для каждого файла объясните, какое поведение должно сохраниться. Затем прочитайте итог целиком и запустите тесты. Технически корректное объединение может потерять важную бизнес-логику.

GitHub Desktop умеет клонировать репозитории, показывать diff, создавать ветки, коммиты, push и pull через интерфейс. Это нормальный способ начать, а не «ненастоящий Git».

Даже в графическом интерфейсе сохраняется та же модель:

· слева выбираются файлы коммита;

· в центре читается diff;

· commit сохраняет локальный снимок;

· push отправляет его на GitHub;

· новая ветка отделяет работу;

· pull получает изменения команды.

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

Создайте приватный репозиторий с README.md, клонируйте его и выполните одну задачу:

1. создайте ветку docs/first-change;

2. добавьте в README инструкцию запуска;

3. посмотрите git diff;

4. подготовьте только README;

5. проверьте staged diff;

6. создайте коммит с понятным сообщением;

7. отправьте ветку;

8. откройте pull request;

9. перечитайте изменение на GitHub;

10. объедините его и обновите локальный main.

Затем специально сделайте лишнюю правку и отмените ее через git restore. Такой безопасный эксперимент лучше закрепляет модель, чем список из двадцати команд.

Git отлично хранит историю отслеживаемых текстовых файлов. Он не заменяет резервную копию базы, пользовательских загрузок, секретов и настроек внешних сервисов. Если сайт зависит от Supabase, Vercel или платежной системы, одного GitHub-репозитория недостаточно для восстановления.

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

Запишите отдельно, что восстанавливается из GitHub, а что из backup других систем. Тогда фраза «все лежит в облаке» не создаст ложную уверенность.

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

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

Важную ветку можно защитить: требовать pull request, успешные проверки и review перед merge. Начинайте с правил, которые команда реально сможет выполнять. Слишком строгая настройка без рабочего CI приводит к обходам.

Три команды помогают понять состояние:

Первая показывает недавние ветки и коммиты, вторая раскрывает один снимок, третья сравнивает рабочую ветку с основной. Перед pull request прочитайте это сравнение как рецензент: нет ли случайного форматирования, generated-файлов и секрета.

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

Удаления файла в новом коммите недостаточно: старое значение остается в истории. Сначала отзовите ключ у провайдера, создайте новый секрет и обновите приложение. Затем решите, нужно ли очищать историю, и предупредите участников о повторном clone.

Включите push protection и secret scanning, если они доступны. Они уменьшают риск, но не распознают любой внутренний формат. Перед staging продолжайте читать новые файлы.

Попросите coding agent составить описание только после того, как вы проверили diff. Сверьте список файлов, тесты и ограничения. Не пишите «все работает», если выполнялась только одна команда.

В review отделяйте замечание о факте от предпочтения. Блокирующими являются неверное поведение, риск данных и отсутствующая проверка. Стиль, который не влияет на проект, можно исправить отдельно, чтобы не раздувать ветку.

После merge удалите рабочую ветку на GitHub и локально, если она больше не нужна, затем обновите main. Это уменьшает визуальный шум, но не удаляет историю вошедших коммитов. Перед новой задачей снова создайте ветку от актуальной основной версии. Так один старый эксперимент не попадет случайно в следующий pull request.

На курсе «Вайб-кодинг: быстрый старт» Git используется как обязательная страховка при работе с coding agents: маленькая задача, просмотр diff, проверка и отдельный коммит.

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