Git и GitHub с нуля

У Бориса сейчас тот самый момент: контекст есть, кода ещё нет.

JobTrack пока — минимальная папка JobTrack на несколько файлов.

jobtrack/
  AGENTS.md
  docs/
    discovery.md

В docs/discovery.md — гипотеза, ограничения и первый MVP. В AGENTS.md — инструкция агенту. Всё.

Нет src/, нет приложения, нет выбранного стека.

И вот тут руки чешутся: открыть агента и сказать — сделай первый экран JobTrack. Я этот зуд знаю.

Это ловушка.

Переписывает не тот файл. Сносит важный раздел из discovery.md. Уходит строить то, чего никто не просил — и Борис уже не поймёт, где именно сломалось. Откатывать нечего.

Вернуть текст руками ещё можно. Только это уже археология по памяти, а не разработка.

Короче, Борису нужен checkpoint до первого кода. И нет, дело не в солидности проекта — без истории изменений агенту нельзя давать файлы. Дашь — уронит, а откатываться некуда)

В модуле 4 у тебя появился workspace JobTrack: папка проекта, docs/discovery.md, AGENTS.md и понятная рамка MVP.

Кода ещё нет.

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

Git нужен не разработчикам для красоты. Он нужен тебе как владельцу проекта — видеть, что изменилось, держать точки, куда откатиться, и не терять работу, когда агент уехал не туда. У меня так и было: агент однажды переписал половину проекта, и Git оказался единственным способом понять, что именно он сломал.

Что такое Git

Git — это локальная история изменений проекта. Он живёт внутри папки и запоминает состояния файлов.

Вот словарь, который встретишь дальше:

— working tree — текущая папка проекта, которую ты видишь; — diff — что поменялось с последнего сохранения; — commit — сохранённый checkpoint; — branch — отдельная линия работы; — merge — влить одну линию работы в другую.

Git работает локально: даже без GitHub можно сделать commit и увидеть diff. И вот тут легко запутаться — GitHub не сам Git. GitHub — место, куда отправляют копию проекта.

Что такое GitHub

GitHub — это сайт и облачное хранилище репозиториев. Проще говоря, это облачная копия проекта плюс место, где историю видно в браузере.

В курсе он нужен, чтобы:

— хранить копию проекта не только на ноутбуке; — дать Codex или другому агенту доступ к репозиторию; — позже делать pull request; — смотреть историю проекта в браузере; — откатиться к понятной точке, когда что-то сломалось.

Локальный и удалённый репозиторий

У JobTrack будет 2 уровня.

Локальный репозиторий — папка jobtrack на твоём компьютере. Там Git хранит историю. Ты работаешь с файлами, агент их меняет, Git показывает diff.

Удалённый репозиторий — копия на GitHub, обычно её называют origin. Готов локальный commit — его отправляют на GitHub через push.

локальная папка jobtrack -> локальный Git -> GitHub remote

commit сохраняет изменения локально. push отправляет commit на GitHub, а pull забирает изменения с GitHub обратно в локальную папку.

Почему Git нужен до первого кода

Проблема с AI-агентом простая: он сделает слишком много.

Без Git ты видишь только итоговую папку. С Git — diff: какие файлы изменились, какие строки добавлены, что удалено.

Для JobTrack первый commit должен сохранить не приложение, а контекст:

— docs/discovery.md; — AGENTS.md; — .gitignore; — по желанию README.md.

Это checkpoint до кода. После него можно просить агента делать маленькие шаги и сравнивать изменения с сохранённой базой.

Короче, сначала фиксируем землю под ногами, потом зовём экскаватор в виде агента.

Как работать через агента

Если ты не разработчик — не лезь в терминал руками.

Открой проект в Codex, Claude Code, Cursor или другом агенте, который видит папку jobtrack, и попроси его выполнить Git-операции.

агент может выполнять команды, но решение о commit принимает человек — после того как сам посмотрел diff.

Перед первой настройкой можно дать такой prompt:

Ты работаешь в папке проекта JobTrack.

Сначала ничего не меняй.

Проверь:
1. что ты находишься в правильной папке проекта;
2. что есть docs/discovery.md и AGENTS.md;
3. что кода приложения ещё нет;
4. установлен ли Git;
5. инициализирован ли локальный Git-репозиторий;
6. есть ли remote на GitHub.

Верни короткий отчёт простыми словами:
- что уже готово;
- чего не хватает;
- какие действия ты предлагаешь сделать дальше.

Хороший агент не бросается делать commit. Сначала проверяет состояние и объясняет, что собирается делать.

Cheat sheet: что сказать агенту

Ниже — не команды для заучивания, а способ ставить агенту маленькие Git-задачи обычными словами.

Что хочешь сделать	Prompt для агента
Начать хранить историю проекта	Проверь, инициализирован ли Git в текущей папке. Если нет, предложи план и инициализируй локальный Git-репозиторий только после моего подтверждения.
Посмотреть состояние	Покажи текущее состояние Git простыми словами: какие файлы изменены, какие staged, есть ли commits, есть ли remote. Ничего не меняй.
Посмотреть изменения	Покажи diff текущих изменений. Не редактируй файлы и не делай commit. После diff кратко объясни, что изменилось.
Подготовить файлы к commit	Подготовь к commit только эти файлы: <список>. Не используй git add . После подготовки покажи staged diff.
Сохранить checkpoint	Сделай commit только из staged изменений с сообщением <сообщение>. После commit покажи status. Push не делай.
Создать копию на GitHub	Объясни, как создать пустой GitHub repo через браузер без README, .gitignore и лицензии. Дай мне шаги, но сам ничего не создавай.
Связать папку с GitHub	Подключи remote origin по этому HTTPS URL: <URL>. Перед изменением покажи, есть ли remote сейчас.
Положить изменения на GitHub	Покажи, какие commits уйдут на GitHub. После моего подтверждения сделай push текущей ветки.
Забрать изменения с GitHub	Проверь, есть ли локальные незакоммиченные изменения. Если чисто, забери изменения с GitHub. Если не чисто, остановись и объясни риск.
Создать новую ветку	Создай новую ветку для задачи <название>. Перед созданием покажи текущую ветку и status.
Влить новую ветку	Объясни, что будет влито из ветки <ветка>. Покажи diff или summary и спроси подтверждение перед merge.
Создать pull request	Подготовь pull request: проверь status, push branch, затем дай ссылку или инструкцию для создания PR. Перед push спроси подтверждение.
Убрать файл из подготовки	Убери <файл> из staged, но не удаляй файл и не стирай правки. Потом покажи status.
Вернуть конкретный файл	Верни только <файл> к последнему commit. Перед этим покажи diff этого файла и спроси подтверждение.

Ветка, merge и pull request в первом проекте не нужны каждый день — держи их в cheat sheet на будущее. Ветка пригодится, когда захочешь пробовать рискованное изменение, не трогая рабочую версию. Merge — когда решишь влить это изменение обратно. Pull request — когда над проектом появится второй человек или ты захочешь ревью перед вливанием.

Для соло-MVP на первых порах хватает commit и push в основную ветку. Жить только в main можно, пока ты один и изменения мелкие — как только начнёшь рисковать, заводи ветку.

Git должен идти маленькими шагами. Если агент предлагает сделать несколько Git-действий сразу, останавливай. Не склеивай опасные шаги в один: status, diff, stage, staged diff, commit, push — по одному за раз.

GitHub и Codex

GitHub-аккаунт заводится обычной регистрацией. Для курса хватает личного аккаунта и приватного или публичного репозитория JobTrack.

В Codex web надо зайти в Codex, нажать Connect GitHub и подключить GitHub-аккаунт. После этого Codex работает с кодом в доступных репозиториях и умеет создавать pull requests.

В Codex app есть локальный, worktree и cloud режимы плюс встроенные Git-инструменты: смотреть diff, stage или revert chunks, делать commit, push и создавать pull request прямо из интерфейса (руками в терминал лезть не придётся).

Если хочешь, чтобы Codex app показывал контекст pull request и комментарии ревьюеров, может понадобиться GitHub CLI gh и авторизация через gh auth login. Для первого проекта — необязательно.

Задача сейчас одна: создать GitHub-репозиторий, подключить его к проекту и отправить первый commit.

Как подключать GitHub без SSH-ключей

Новичку не нужно начинать с SSH-ключей. Самый простой маршрут для курса — Codex web: подключить GitHub через кнопку Connect GitHub и дать доступ к нужному репозиторию.

Есть ещё два маршрута. В Codex app или IDE — работать с локальной папкой, а агент сам попросит авторизацию через браузер, если она понадобится. Или создать пустой repo на GitHub в браузере, скопировать HTTPS URL и дать его агенту:

Вот URL пустого GitHub-репозитория: <URL>.
Подключи его как remote origin, отправь текущий main на GitHub.
Перед push покажи, какие commits будут отправлены.

Если инструмент просит токен или пароль — не клади его в файлы проекта. Токен в docs или AGENTS.md уедет на GitHub с первым же push, и это будет твой слитый доступ. Авторизация живёт в инструменте, браузере, GitHub CLI или системном credential manager.

Промпты для агента

Плохой prompt:

Сделай GitHub и закоммить всё.

Слишком широкий. Агент добавит лишние файлы, накидает кодовый каркас, закоммитит мусор и отправит это на GitHub. И теперь твоя история проекта начинается не с чистого контекста, а с помойки.

Хороший prompt:

Мы в проекте JobTrack. Кода ещё нет.

Подготовь Git и GitHub до первого кода.

Правила:
- сначала проверь docs/discovery.md и AGENTS.md;
- не создавай src/, app/, components и кодовый каркас;
- если Git не инициализирован, предложи инициализацию;
- создай .gitignore только для базовых исключений;
- подготовь к первому commit только docs/discovery.md, AGENTS.md, .gitignore и README.md по желанию;
- перед commit покажи git status и staged diff;
- commit делай только после моего подтверждения;
- push делай только после моего подтверждения.

Верни план и жди подтверждения перед изменениями.

Разница простая: решение о сохранении остаётся у тебя, агент делает только технику.

Частые ошибки

Путать Git и GitHub.

Git — локальная история, GitHub — удалённая копия и интерфейс вокруг неё. Если смешать эти вещи, легко думать, что без GitHub у тебя нет истории, или что один push уже заменяет нормальный commit.

Делать Git после аварии.

Если агент уже переписал половину проекта, Git не покажет нормальный до/после. Сначала checkpoint, потом изменения.

Коммитить всё подряд.

git add . удобен, но на старте добавляй файлы явно. Меньше шанс сохранить мусор.

Не читать diff.

Не читал diff — не знаешь, что сохраняешь. Пересказ агента не считается.

Просить агента сделать commit и push без подтверждения.

Так Git из защиты превращается в конвейер случайных изменений.

Сносить всё жёстким откатом, когда нужен один файл.

git reset --hard сносит работу без спроса. Это не команда для новичка. Для учебного проекта возвращай конкретный файл через редактор или точечный restore.

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

Я сам всегда так: сначала status, потом diff, потом staged diff, потом commit — и только потом push.

В этой практике ты не учишься быть терминальным ниндзя. Ты учишься ставить агенту безопасную задачу: подготовить Git и GitHub для JobTrack, показать diff и не сохранять ничего без твоего подтверждения.

Результат модуля — GitHub-репозиторий с первым commit до кода и правило в AGENTS.md: план до правок, diff после правок, commit и push только по просьбе.

SPP preflight

Перед настройкой Git попроси агента выбрать безопасный workflow:

Используй /spp.

Мы на модуле 5. Workspace уже создан, в проекте есть docs/discovery.md и AGENTS.md, кода приложения ещё нет.

Нужно подготовить Git и GitHub:
- проверить окружение;
- создать первый Git checkpoint;
- связать локальный проект с GitHub;
- добавить правило Git в AGENTS.md;
- не писать код;
- не делать commit и push без отдельного подтверждения.

Если у SPP нет отдельного skill под этот шаг, это нормально: агент должен прямо сказать об этом и дальше работать через /spp, а не выдумывать несуществующий workflow.

Практика 1. Регистрация и настройка окружения

Сначала подготовь доступы.

1. Создай GitHub-аккаунт или проверь, что он уже есть.
2. Подтверди email.
3. Создай пустой репозиторий jobtrack или с именем твоего проекта на GitHub.
4. Не добавляй README, .gitignore и лицензию на сайте GitHub. .gitignore придёт из локального проекта, а полноценный README появится позже, в модуле 15. Пустой репозиторий нужен, чтобы первый commit пришёл из твоего проекта, а не с сайта. Иначе с самого начала получишь лишний merge-пустяк, который сейчас вообще не нужен.
5. Скопируй HTTPS URL репозитория.

Дальше подключение GitHub зависит от инструмента:

• Дорожка A (Codex App): открой локальную папку jobtrack в Codex app. Для первого модуля достаточно Local-режима. Если работаешь через Codex web, подключи GitHub через Connect GitHub и разреши доступ к репозиторию JobTrack — это позволит Codex работать с репозиторием и создавать pull requests. Если позже понадобится pull request context в app, может пригодиться GitHub CLI и авторизация через gh auth login, но сейчас это не обязательный шаг.
• Дорожка B (Claude Code): открой папку jobtrack в Claude Code, запустив его из этой папки. Главное, чтобы агент видел файлы проекта и мог выполнять Git-операции или хотя бы подсказать, чего не хватает. Другие инструменты (Cursor, IDE-агенты) подключаются так же: важно, чтобы агент видел папку проекта.

Дай агенту prompt:

Ты работаешь в папке моего проекта.

Сначала ничего не меняй.

Проверь окружение:
1. ты находишься в правильной папке проекта;
2. есть docs/discovery.md;
3. есть AGENTS.md или проектная инструкция агенту;
4. кода приложения ещё нет;
5. Git доступен;
6. локальный Git-репозиторий уже инициализирован или нет;
7. remote GitHub уже подключён или нет.

Верни отчёт простыми словами:
- что готово;
- чего не хватает;
- какой следующий безопасный шаг.

Если агент пишет, что Git не установлен или GitHub не подключён, не надо героически чинить всё самому. Попроси его объяснить следующий шаг для твоего инструмента: Codex app, Codex web, Cursor, Claude Code или обычный терминал.

Практика 2. Работа с конкретным репозиторием

Теперь попроси агента подготовить первый checkpoint. Тут лучше быть занудой, чем потом разбирать первый commit с секретами и случайным scaffold.

Prompt:

Мы в моём проекте. Кода ещё нет.

Задача: подготовить первый Git checkpoint и связать проект с GitHub.

Правила:
- работай только с текущей папкой проекта;
- перед изменениями покажи план;
- не создавай src/, app/, components, базу данных и конфиги фреймворка;
- если Git не инициализирован, инициализируй локальный Git-репозиторий только после того, как я подтвержу план;
- создай или проверь .gitignore с базовой защитой .env и .env.*;
- подготовь к первому commit только docs/discovery.md, AGENTS.md, .gitignore и README.md по желанию;
- перед commit покажи git status и staged diff;
- commit делай только после моего подтверждения;
- push делай только после моего подтверждения.

GitHub remote:
<ВСТАВЬ_HTTPS_URL_ПУСТОГО_REPO>

Сначала верни план и жди моего подтверждения.

Хороший план агента должен быть коротким:

План:
1. Проверю docs/discovery.md и AGENTS.md.
2. Проверю, есть ли Git-репозиторий.
3. Если Git не включён, инициализирую его.
4. Создам/проверю .gitignore.
5. Подготовлю только стартовые документы к commit.
6. Покажу git status и staged diff.
7. Commit и push сделаю только после подтверждения.

После плана разреши агенту выполнить подготовку.

Когда агент покажет staged diff, проверь 3 вещи:

• в commit попадают docs/discovery.md, AGENTS.md, .gitignore и optional README.md;
• в commit не попадают src/, app/, components, конфиги фреймворка и код приложения;
• в commit не попадают .env, токены, ключи, приватные файлы и личные документы.

Если diff нормальный, дай отдельное подтверждение:

Diff проверен. Сделай первый commit с сообщением:
docs: добавить стартовый контекст проекта

После commit покажи git status и не делай push без отдельного подтверждения.

После commit проверь ответ агента. Если всё нормально, разреши push:

Теперь подключи remote GitHub, если он ещё не подключён, и отправь main на GitHub.

Remote URL:
<ВСТАВЬ_HTTPS_URL_ПУСТОГО_REPO>

Перед push покажи, какие commits будут отправлены.
После push покажи git status и ссылку на репозиторий.

Открой GitHub в браузере и проверь, что там появились стартовые файлы проекта.

Добавь правило агенту

Теперь зафиксируй в AGENTS.md, как агент должен работать с Git.

Prompt:

Добавь в AGENTS.md короткий раздел Git и изменения.

Правила:
- перед правкой показывать короткий план;
- после правки показывать git diff и команды проверки;
- commit делать только по моей прямой просьбе;
- push делать только по моей прямой просьбе;
- не использовать git reset --hard;
- не добавлять .env, ключи, токены и приватные файлы.

Не меняй другие разделы.
Перед правкой покажи план.
После правки покажи diff.
Commit не делай.

После diff сделай отдельный commit и push через агента:

Diff проверен. Сделай commit:
docs: добавить правила работы с git

После commit покажи status. Push сделай только после моего следующего сообщения.

Потом:

Отправь новый commit на GitHub и покажи итоговый status.

Cheat sheet для практики

Что нужно	Prompt агенту
Проверить состояние	Покажи git status простыми словами. Ничего не меняй.
Посмотреть изменения	Покажи git diff и кратко объясни изменения. Ничего не коммить.
Подготовить первый commit	Подготовь к commit только docs/discovery.md, AGENTS.md, .gitignore и README.md по желанию. Потом покажи staged diff.
Сделать commit	Diff проверен. Сделай commit с сообщением <сообщение>. После commit покажи status. Push не делай.
Отправить на GitHub	Покажи, какие commits будут отправлены. После моего подтверждения сделай push.
Забрать изменения	Проверь, чистый ли working tree. Если чистый, сделай pull. Если нет, остановись и объясни риск.
Создать новую ветку	Создай ветку <название> для отдельной задачи. Перед этим покажи status.
Влить ветку	Покажи, что изменилось в ветке <название>, и спроси подтверждение перед merge.
Создать pull request	Подготовь pull request для текущей ветки. Перед push спроси подтверждение.
Убрать лишний staged-файл	Убери <файл> из staged, не удаляя файл и не стирая правки. Потом покажи status.
Вернуть конкретный файл	Покажи diff файла <файл>. После моего подтверждения верни только этот файл к последнему commit.