GitHub: сохранить и не потерять

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

Без GitHub любая ошибка превращается в час попыток вспомнить «а что я трогал». С GitHub — кнопка отката к последней рабочей версии. Это одна из тех штук которые ставишь в первый день и больше никогда не работаешь без них.

Зачем нужен GitHub

Представь Google Docs с историей версий — только не для одного документа, а для всех файлов проекта сразу. Именно так и работает GitHub.

На практике это три вещи. Первая — откат. Что-то сломалось после изменений, нажал несколько команд и вернул рабочую версию, не разбираясь что именно пошло не так.

Вторая — резервная копия. Проект хранится не только на твоём компьютере. Сломался ноутбук, переехал на новую машину — зашёл на github.com, скачал, продолжил.

Третья — деплой. Такие хостинги как Vercel и Netlify подключаются прямо к GitHub. Запушил изменения — сайт обновился автоматически, без лишних действий. Как это работает разберём в следующей статье.

Создать репозиторий

Репозиторий — это папка проекта на GitHub. Сначала создаём её там, потом связываем с локальной папкой на компьютере.

Шаг первый: регистрируешься на github.com, если ещё нет аккаунта. Шаг второй: нажимаешь кнопку «New repository», даёшь имя проекту, нажимаешь «Create repository».

Шаг третий: связываешь локальную папку с репозиторием. Открываешь терминал в папке проекта и выполняешь по очереди:

git init
git add .
git commit -m "Первый коммит"
git remote add origin https://github.com/username/repo-name.git
git push -u origin main

Замени username на своё имя на GitHub, repo-name — на имя репозитория. После этой привязки достаточно просто писать git push — больше не надо указывать куда именно.

Если хочется проще — есть GitHub CLI. Расскажу дальше.

Commit и Push — что это

Commit — сохранить текущее состояние с подписью «что сделал». Push — отправить это сохранение на GitHub.

Аналогия простая: commit — это нажать «сохранить» в игре. Push — это загрузить сохранение в облако, чтобы оно было не только у тебя.

# Посмотреть что изменилось
git status

# Добавить изменённые файлы
git add .

# Сохранить с описанием
git commit -m "Добавил форму обратной связи"

# Отправить на GitHub
git push

Пример рабочего дня с git

Чтобы сразу было понятно как это вплетается в работу — вот обычный день когда ты делаешь сайт:

Утро    → доделал шапку сайта → "Сделай коммит: 'Готова шапка'"
День    → собрал блок «Услуги»  → "Коммит: 'Добавил услуги'"
Вечер   → форма заработала      → "Коммит: 'Форма обратной связи работает'"
Ухожу   → "Сделай пуш"           ← один раз в конце дня

В следующий раз когда сядешь — уже на GitHub есть точки возврата
к каждой работающей версии. Сломалось? Откатился к утреннему коммиту.

Совет от практики: фраза «сделай коммит и пуш» должна стать привычной как «сохрани документ». Один раз закроешь ноутбук без пуша — потом потратишь час на восстановление того что забыл сохранить.

Типичные ошибки новичков

GitHub CLI — проще чем SSH

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

GitHub CLI решает это элегантно: авторизация через браузер, без ключей. Ставишь утилиту, один раз логинишься — и git push работает без паролей и ключей навсегда.

# macOS
brew install gh

# Авторизация (откроет браузер)
gh auth login

После gh auth login браузер откроет страницу GitHub с подтверждением. Нажимаешь разрешить — готово. Больше никаких вопросов про пароли при пуше.

.gitignore — что не пушить в интернет

.gitignore — это файл в корне проекта, который говорит git: «вот эти файлы и папки — никогда не пуши». Он невидимый снаружи, но работает всегда.

Без него легко случайно опубликовать в публичный репозиторий ключи API, пароли от базы данных или личные настройки. Это реальная проблема: GitHub регулярно сканируется ботами, которые ищут именно такие утечки. Нашли твой ключ от OpenAI — через час у тебя списание на несколько тысяч долларов.

Вот что обязательно должно быть в .gitignore:

.env и .env.* — файлы с переменными окружения. Сюда обычно кладут API-ключи и пароли. Никогда, ни при каких обстоятельствах, не пуши их в GitHub.

node_modules/ — огромная папка с зависимостями. Может весить сотни мегабайт. Её не нужно хранить в гит — любой может восстановить командой npm install.

.DS_Store — системные файлы macOS. Создаются автоматически в каждой папке. Никому кроме твоей машины они не нужны.

.claude/settings.local.json — личные настройки Claude Code. Claude при первом запуске сам добавляет этот файл в .gitignore, но лучше проверить что он там есть.

Что не надо игнорировать — и это частая ошибка новичков:

CLAUDE.md должен быть в гит — вся команда должна видеть правила проекта. .claude/settings.json — общие настройки проекта, их тоже шарить. .claude/agents/ — конфигурации субагентов, тоже в репозиторий.

# Секреты и ключи — НИКОГДА не в гит
.env
.env.*
.env.local
*.key
*.pem

# Зависимости
node_modules/
.pnp

# Система
.DS_Store
Thumbs.db

# Claude Code — личные настройки
.claude/settings.local.json

# Временные файлы
*.log
dist/
build/
.cache/

Ветки и Pull Request

Пока у тебя один проект и работаешь один — всё живёт в одной ветке main. Каждый коммит идёт прямо в неё. Это нормально для соло-сайтов, но как только захочешь что-то экспериментально попробовать или работать вдвоём — нужны ветки и Pull Request.

Зачем ветки

Ветка — это параллельная линия истории проекта. Хочешь попробовать новую фичу, но не уверен что получится — создаёшь ветку, экспериментируешь там. Получилось — сливаешь в main. Не получилось — выкидываешь, основной проект не пострадал.

Создай новую ветку для эксперимента: попробуем темную тему сайта.
Назови её feature/dark-theme.

После работы:
"Слей feature/dark-theme в main и удали ветку"
или
"Я передумал. Удали feature/dark-theme, остался на старом."

Зачем Pull Request

Pull Request (PR) — это запрос на слияние ветки в main с возможностью посмотреть и обсудить изменения до слияния. На GitHub это страница со списком всех изменений, с комментариями и кнопкой «Merge».

Когда полезно даже если работаешь один: Claude поработал в feature-ветке, создал PR — ты смотришь что именно поменялось (вся диффа на одной странице), и только потом сливаешь в main. Никаких сюрпризов в боевом коде.

Создай Pull Request из текущей ветки в main.
Заголовок: «Тёмная тема сайта».
В описании — что именно изменилось и почему.

Если установлен GitHub CLI — Claude сделает PR одной командой gh pr create, ты получишь ссылку. Без CLI — Claude напишет описание и подскажет как создать PR через интерфейс GitHub.

Защита main (для команд)

В платном GitHub (Teams и выше) можно включить защиту ветки main: напрямую пушить запрещено, изменения — только через PR. Для соло-проектов это необязательно, но хорошая привычка для дисциплины.

Git Worktree — для совсем продвинутых

Это редко нужная штука для новичка — можно пока пропустить и вернуться когда станет тесно работать в одной копии проекта. Но раз заговорили про ветки — расскажу что есть и как работает, чтобы не было «у меня в статьях слово появляется без объяснения».

Сначала разберёмся со словами

Чтобы понять worktree — нужно знать три вещи:

• Ветка — параллельная линия истории проекта. По умолчанию все работают в ветке main (главная). Можно создать другую ветку, например experiment, и в ней что-то пробовать. Пока ты в ветке experiment — изменения не попадают в main. Это как параллельные миры — в одном ты делаешь стандартный сайт, в другом экспериментируешь с новым дизайном.
• main — название основной ветки в твоём репозитории. Считай это «официальной версией». Всё что лежит в main — это то что в итоге увидят пользователи на твоём боевом сайте.
• Слить ветку (merge) — взять изменения из одной ветки и добавить их в другую. Эксперимент удался → сливаешь ветку experiment в main → теперь твои эксперименты стали официальной версией.

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

В чём проблема и зачем нужен worktree

Представь ситуацию: ты попросил Claude Code сделать новую страницу — он работает в ветке new-page. Через 20 минут заходит клиент и говорит «срочно поправь баг на главной». Ты должен переключиться на main, но Claude в этой же папке делает другую задачу. Если переключишься — все его файлы поменяются на состояние main, его работа пропадёт.

Worktree решает это. Он создаёт вторую папку того же проекта на твоём компьютере, привязанную к другой ветке. Получается две папки одного проекта — в одной Claude доделывает new-page, в другой ты чинишь баг в main. Они не мешают друг другу.

Как пользоваться

Самый простой путь — slash-команда прямо в чате Claude Code. Если у тебя установлен скилл/плагин worktree (он есть в плагине superpowers и устанавливается одной командой — см. статью 05a):

/worktree имя-задачи

Claude сам создаст папку, ветку, переключит сессию в новый worktree — за пару секунд без ручных команд git. Это самый удобный способ, рекомендую начинать с него.

Альтернатива №1 — попросить Claude обычными словами (если скилла нет, но ставить не хочется):

Создай git worktree для новой задачи [короткое описание задачи].

Имя ветки: feature/[имя-задачи].
Папку положи рядом с основным проектом, на уровень выше (../).

После создания — открой эту папку в новом окне VS Code,
там я буду работать над этой задачей. Основной проект
оставь как есть.

Альтернатива №2 — встроенный флаг при запуске Claude Code из терминала. Запускаешь Claude уже сразу в новом worktree:

claude --worktree имя-задачи

Если интересно что происходит «под капотом» — Claude (или флаг) в итоге выполняет такие git-команды:

# Создать новую папку рядом с проектом (../) с новой веткой внутри
git worktree add ../my-project-feature feature/имя-задачи

# Посмотреть какие worktree есть
git worktree list

# Удалить worktree когда закончил
git worktree remove ../my-project-feature

Префикс ../ в путях означает «на уровень выше текущей папки». То есть если основной проект лежит в /Users/me/Projects/my-site/, то ../my-site-feature создаст папку /Users/me/Projects/my-site-feature/ — рядом с основным проектом, не внутри него.

Когда закончил — слить и удалить

После того как фича готова в worktree-папке, нужно перенести её в основной проект. Это делается через слияние веток. Тоже можно попросить Claude:

Фича в worktree готова. Слей ветку feature/[имя-задачи] в main
в основном проекте, потом удали worktree-папку.

Если есть конфликты при слиянии — покажи их и помоги разобраться.

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