4.1: Git и GitHub

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

Обзор

Представь ситуацию: ты три часа работал над новой фичей, и вдруг всё сломалось. Экран белый, ошибки сыпятся, а ты не помнишь, что именно изменил. Знакомо? Если у тебя не настроен Git, единственный вариант -- начинать заново или мучительно искать проблему. Если настроен -- одна команда, и ты вернулся к последней рабочей версии. Это как кнопка «отменить» (Ctrl+Z), но для всего проекта целиком.

Git -- это система контроля версий, стандарт индустрии с 2005 года. Её создал Линус Торвальдс (да, тот самый, который создал Linux) для управления разработкой ядра операционной системы. С тех пор Git стал инструментом номер один для всех, кто работает с кодом -- от одиночных разработчиков до команд в тысячи человек.

GitHub -- это платформа, которая хранит твои Git-репозитории в облаке и добавляет сверху массу полезных функций: совместную работу, отслеживание задач, автоматизацию и, что особенно важно для нас, автоматический деплой. Когда ты пушишь код на GitHub, Vercel (или другой хостинг) мгновенно подхватывает изменения и обновляет сайт. Это называется CI/CD -- continuous integration / continuous deployment.

Для соло-фаундера Git и GitHub решают три критические задачи. Во-первых, бэкап: если твой ноутбук сломается, утонет или его украдут, весь код в безопасности на серверах GitHub. Во-вторых, история: ты видишь, что именно менялось, когда и почему -- это спасает при отладке. В-третьих, автодеплой: вместо ручного копирования файлов на сервер, ты просто делаешь git push, и через 30 секунд обновлённый сайт уже в интернете. Это не просто удобство -- это профессиональный workflow, который используют все серьёзные компании.

Не переживай, если Git кажется сложным. На самом деле в ежедневной работе ты будешь использовать всего 3-4 команды, а Claude поможет с настройкой и объяснит каждый шаг. К концу этого урока у тебя будет полностью настроенный репозиторий с автодеплоем, и ты будешь чувствовать себя уверенно в этом workflow.

Чему научишься

Как работает Git: концепция «сохранений»

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

В Git «сохранение» называется commit (коммит). Каждый коммит -- это снимок всего проекта в определённый момент времени. У каждого коммита есть описание: «Добавил страницу с ценами» или «Исправил баг в форме оплаты». Это позволяет не только откатиться к любой точке, но и понять, что происходило с проектом.

Вот как выглядит типичная история коммитов:

abc1234 - Добавил аналитику Яндекс.Метрики (2 часа назад)
def5678 - Исправил отображение на мобильных (вчера)
ghi9012 - Подключил платёжную страницу (2 дня назад)
jkl3456 - Первый коммит: базовый лендинг (неделю назад)

Каждый из этих коммитов -- точка, к которой можно вернуться. Если аналитика сломала что-то на сайте, ты можешь откатиться к def5678 и разобраться, что пошло не так.

Важно понимать разницу между тремя «зонами» Git. Working directory -- это твоя рабочая папка с файлами, где ты вносишь изменения. Staging area (индекс) -- это «черновик коммита», куда ты добавляешь файлы, которые хочешь включить в следующее сохранение. Repository -- это собственно база данных всех коммитов. Эта трёхступенчатая система даёт контроль: ты можешь изменить десять файлов, но в коммит включить только три -- те, которые относятся к одной конкретной задаче.

GitHub: облачное хранилище и не только

Если Git -- это система сохранений на твоём компьютере, то GitHub -- это облачное хранилище для этих сохранений. Когда ты делаешь git push, все твои коммиты загружаются на серверы GitHub. Теперь они доступны с любого устройства и защищены от потери.

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

Ещё одна критическая функция GitHub -- интеграция с хостингами. Vercel, Netlify, Railway и другие платформы умеют «слушать» твой GitHub-репозиторий. Как только ты пушишь новый коммит, хостинг автоматически скачивает код, собирает проект и обновляет сайт. Весь процесс занимает 30-60 секунд. Это и есть тот самый автодеплой, ради которого стоит настроить всё с самого начала.

GitHub бесплатен для публичных и приватных репозиториев. Для стартапа на ранней стадии бесплатного тарифа более чем достаточно. Ты получаешь неограниченное количество репозиториев, 500 МБ хранилища для пакетов и 2000 минут автоматизации в месяц.

Ежедневный workflow: add, commit, push

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

git add . -- добавляет все изменённые файлы в staging area. Точка означает «все файлы в текущей директории». Можно также добавлять конкретные файлы: git add index.html styles.css.

git commit -m "Описание изменений" -- создаёт коммит (сохранение) с описанием того, что ты сделал. Описание важно -- через месяц ты будешь благодарен себе за понятные сообщения. Плохо: "fix". Хорошо: "Исправил отображение кнопки на мобильных".

git push -- отправляет коммиты на GitHub. После этого изменения в безопасности, и если подключён автодеплой, сайт обновится автоматически.

Вот и всё. Три команды. add -- commit -- push. Это как «сохранить файл» в Word, только для всего проекта сразу. Claude поможет тебе запомнить этот паттерн, а со временем он станет автоматическим.

Есть ещё несколько команд, которые пригодятся время от времени:

git status -- показывает, какие файлы изменены, какие добавлены в staging, какие не отслеживаются. Полезно перед коммитом, чтобы убедиться, что всё правильно.

git log --oneline -- компактная история коммитов. Помогает вспомнить, что ты делал и когда.

git diff -- показывает конкретные изменения в файлах. Что добавлено, что удалено, что изменено.

Файл .gitignore: что не нужно сохранять

Не все файлы в проекте нужно отслеживать и загружать на GitHub. Некоторые файлы генерируются автоматически (папка node_modules с зависимостями), некоторые содержат секретные данные (файл .env с ключами API), а некоторые просто мусор (.DS_Store на macOS).

Файл .gitignore -- это список того, что Git должен игнорировать. Он лежит в корне проекта и выглядит так:

node_modules/
.env
.env.local
.DS_Store
.next/
out/
*.log

Claude создаёт правильный .gitignore автоматически при инициализации проекта, но важно понимать его назначение. Если ты случайно закоммитишь файл .env с API-ключами, любой, кто увидит репозиторий, получит доступ к твоим сервисам. Это серьёзная проблема безопасности, и .gitignore -- первая линия защиты.

Почему GitHub критичен для соло-фаундера

Многие начинающие фаундеры думают: «Я работаю один, зачем мне Git и GitHub? Я просто буду сохранять файлы на диск». Это опасное заблуждение, и вот почему.

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

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

Автодеплой -- практическая причина. Без GitHub тебе придётся вручную копировать файлы на сервер каждый раз, когда ты что-то меняешь. С GitHub это происходит автоматически. Ты работаешь над кодом, делаешь git push, и через минуту сайт обновлён. Это экономит часы времени и убирает целый класс ошибок.

Что ты создашь

• Локальный Git-репозиторий -- инициализируешь систему контроля версий в папке проекта
• GitHub-репозиторий -- создашь удалённый репозиторий и свяжешь его с локальным
• Файл .gitignore -- настроишь список игнорируемых файлов для безопасности и чистоты
• Первый коммит -- сделаешь полноценное сохранение проекта с осмысленным описанием
• Первый push -- загрузишь код на GitHub и убедишься, что всё работает
• Связь с Vercel -- подключишь автодеплой, чтобы каждый push обновлял сайт

Как это работает на практике

Шаг 1: Установка и настройка Git

Claude проверит, установлен ли Git на твоём компьютере. На macOS Git обычно предустановлен; на Windows его нужно скачать с git-scm.com. После установки настроим имя и email -- эти данные будут записываться в каждый коммит, чтобы было понятно, кто внёс изменения.

Шаг 2: Создание GitHub-аккаунта и репозитория

Если у тебя ещё нет аккаунта на GitHub, создадим его. Затем создадим новый репозиторий (repository) -- это «папка» на GitHub, где будет храниться твой проект. Репозиторий может быть публичным (видно всем) или приватным (видно только тебе). Для MVP рекомендуем приватный -- потом можно сделать публичным.

Шаг 3: Инициализация и первый коммит

Инициализируем Git в папке проекта командой git init, настроим .gitignore, добавим все файлы в staging и сделаем первый коммит. Claude объяснит каждую команду и убедится, что всё прошло успешно.

Шаг 4: Подключение к GitHub

Свяжем локальный репозиторий с GitHub-репозиторием командой git remote add origin. Затем сделаем первый push -- загрузим код в облако. После этого ты сможешь открыть GitHub в браузере и увидеть свои файлы.

Шаг 5: Настройка автодеплоя через Vercel

Подключим GitHub-репозиторий к Vercel. Процесс простой: заходишь на vercel.com, авторизуешься через GitHub, выбираешь репозиторий -- и Vercel автоматически настроит деплой. Теперь каждый git push будет запускать обновление сайта.

Шаг 6: Практика workflow

Сделаем небольшое изменение в проекте (например, поправим текст на главной) и пройдём полный цикл: add -- commit -- push. Убедимся, что коммит появился на GitHub и сайт обновился автоматически.

Лучшие практики

• Коммить часто, но осмысленно. Не жди конца дня, чтобы сделать один гигантский коммит с описанием «много изменений». Коммить после каждой завершённой задачи: добавил секцию -- коммит, исправил баг -- коммит, обновил стили -- коммит. Маленькие коммиты легче откатить и проще понять.

• Пиши понятные commit messages. Сообщение коммита -- это послание будущему тебе. Через месяц "fix" не скажет ничего, а "Исправил ошибку 404 на странице оплаты" -- скажет всё. Хороший формат: глагол + что сделано + где.

• Никогда не коммить секреты. Файлы .env, API-ключи, пароли -- ничего из этого не должно попасть в репозиторий. Даже если репозиторий приватный. Даже если ты потом удалишь файл -- он останется в истории коммитов. Проверяй .gitignore перед первым коммитом.

• Используй git status перед коммитом. Привычка проверять, что именно будет закоммичено, спасает от случайного включения лишних файлов. Одна лишняя секунда на git status может сэкономить часы на разбирательства.

• Делай push после каждого коммита. Коммит без push -- это сохранение, которое существует только на твоём компьютере. Если ноутбук сломается, оно пропадёт. Push отправляет коммит на GitHub, и теперь он в безопасности. Формула простая: add -- commit -- push, всегда вместе.

• Не бойся ошибок. Git спроектирован так, что практически любое действие можно отменить. Случайно добавил файл в staging? git reset. Сделал плохой коммит? git revert. Всё запутал? Claude поможет разобраться. Git -- это сетка безопасности, а не минное поле.

• Именуй репозитории понятно. Используй lowercase с дефисами: my-startup-landing, flowai-app, payment-service. Не используй пробелы, кириллицу и спецсимволы в названии репозитория.

Частые вопросы

Что если я случайно закоммитил секретный файл (.env)? Это серьёзная ситуация, но решаемая. Сначала добавь файл в .gitignore и сделай новый коммит. Затем смени все скомпрометированные ключи и пароли -- они уже в истории Git и потенциально видны. Для полного удаления из истории есть команда git filter-branch, но она сложная -- попроси Claude помочь. Главный урок: проверяй .gitignore до первого коммита.

Нужен ли мне Git, если я использую Claude Code? Однозначно да. Claude Code вносит изменения в файлы, и Git позволяет отслеживать каждое такое изменение. Если Claude сделал что-то не так, ты можешь откатиться к предыдущей версии. Без Git ты зависишь от удачи. С Git -- ты контролируешь процесс.

В чём разница между Git и GitHub? Git -- это программа на твоём компьютере, которая отслеживает изменения в файлах. GitHub -- это сайт, где эти изменения хранятся в облаке. Git работает локально, GitHub -- удалённо. Ты можешь использовать Git без GitHub, но GitHub без Git -- нет. Это как разница между текстовым редактором (Git) и Google Docs (GitHub): один работает на компьютере, другой -- в облаке.

Могу ли я использовать GitLab или Bitbucket вместо GitHub? Да, все три платформы работают с Git и выполняют схожие функции. Мы рекомендуем GitHub по трём причинам: лучшая интеграция с Vercel, самое большое сообщество и бесплатный тариф покрывает все потребности стартапа. Но если у тебя уже есть аккаунт на GitLab или Bitbucket -- можно использовать их.

Как часто нужно делать коммиты? Как минимум -- после каждой завершённой задачи. Добавил новую секцию на сайт -- коммит. Исправил ошибку -- коммит. Обновил стили -- коммит. В среднем это 5-15 коммитов в день активной работы. Нет такой вещи как «слишком много коммитов», но есть «слишком мало». Один коммит в конце дня -- это плохая практика.

Мне нужно знать командную строку, чтобы работать с Git? Базовые команды (add, commit, push, status) достаточно просто запомнить, и Claude будет подсказывать их каждый раз. Есть также графические интерфейсы (GitHub Desktop, VSCode Git panel), но командная строка -- самый надёжный и быстрый способ. Уже через неделю использования эти команды станут автоматическими.

Запуск

/start-4-1

Следующий урок: Деплой и запуск -->