Git с Claude Code: первые ветки, коммиты и pull request

Вы поручили агенту поправить форму заявки. Через полчаса на экране всё работает, а в папке изменились семь файлов. Какие правки относятся к задаче? Что сохранить? Как передать результат разработчику и вернуться к предыдущему состоянию при ошибке? На эти вопросы помогает отвечать Git.

Git хранит историю изменений проекта. Claude Code может выполнять его команды, читать различия файлов и объяснять происходящее. Для уверенной работы достаточно понять несколько понятий и освоить один короткий цикл. Разберём его на учебном примере: в форме заказа нужно запретить отправку заявки с пустым телефоном.

Что именно хранит Git

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

Между рабочей папкой и коммитом есть индекс, или staging area: туда отбирают изменения для следующего сохранения. Поэтому изменение файла и создание коммита — разные действия. Вы можете исправить пять файлов, а в ближайший коммит включить только два, относящихся к одной задаче.

Ветка — отдельная линия работы. Основная ветка часто называется main, но имя зависит от проекта. Удалённый репозиторий — копия истории на GitHub или другом сервере. Команда push отправляет туда локальные коммиты. Pull request, сокращённо PR, предлагает объединить изменения ветки с целевой веткой и даёт место для проверки и обсуждения.

Шаг 1. Узнать состояние проекта

Откройте правильную папку и попросите агента провести осмотр. На этом этапе важно увидеть существующие изменения: они могли остаться от другой задачи или другого человека.

Покажи состояние Git в текущей папке: корень репозитория, текущую ветку, изменённые и новые файлы, последние пять коммитов. Кратко объясни, есть ли незавершённая работа. Не меняй файлы, индекс, ветку или историю. Содержимое файлов с секретами не выводи.

Обычно для такого осмотра достаточно git status, git branch --show-current, git diff --stat и git log --oneline -5. Если Git сообщает, что репозиторий отсутствует, сначала уточните расположение проекта. Автоматическая инициализация в случайной родительской папке создаст путаницу.

Предположим, агент показал чистую рабочую папку и ветку main. Это удобное начало упражнения. Если уже есть изменения, выясните, кому они принадлежат и как связаны с текущей задачей. Сохраните их отдельным понятным шагом, прежде чем переключать базу работы.

Шаг 2. Создать ветку и описать результат

Для учебной задачи подойдёт имя fix/order-phone. Ветка создаётся от проверенной базы. В командном проекте перед началом стоит посмотреть удалённые изменения через fetch и выяснить, актуальна ли локальная основная ветка. Fetch получает сведения с сервера; дальнейшее объединение истории требует отдельного решения.

Нужно исправить форму заказа: пустой телефон должен останавливать отправку и показывать понятную ошибку. Проверь чистоту рабочей папки и актуальность согласованной основной ветки. Создай от неё ветку fix/order-phone. Найди обработчик формы, внеси минимальное исправление и проверь пустой, неверный и корректный номер. Сохраняй существующие изменения других участников. Коммит и отправку на сервер пока не выполняй.

Попросите агента назвать файлы, которые он собирается менять. Для нашей задачи это может быть компонент формы и существующий файл тестов. Внезапное обновление десятков зависимостей требует объяснения: оно увеличивает объём проверки и затрудняет понимание результата.

Шаг 3. Прочитать diff и проверить поведение

Diff показывает добавленные и удалённые строки. Начните с общего списка, затем откройте различия нужных файлов. Даже новичок может проверить текст сообщения, название поля и отсутствие посторонних изменений. Сложную логику попросите объяснить по шагам на конкретных значениях.

В форме проверьте три пути. Пустой телефон должен давать сообщение рядом с полем. Неправильный формат — понятную подсказку. Корректный номер — проходить дальше по существующему сценарию. Клиентская проверка улучшает интерфейс; сервер всё равно должен проверять входные данные независимо.

Уточните среду проверки. Формулировка «проверено локально» относится к рабочей копии. После публикации сайта отдельно проверяют публичную форму и реальное создание заявки. Коммит, успешный тест и отправка ветки на GitHub сами по себе сайт не обновляют.

Шаг 4. Подготовить и создать коммит

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

Подготовь коммит по исправлению телефона. Покажи список файлов, краткое объяснение diff, запущенные проверки и ограничения. Проверь отсутствие временных выгрузок, логов и секретов в выбранных изменениях. После согласования добавь только перечисленные файлы в индекс, покажи staged diff и создай коммит в стиле проекта. Чужие изменения сохрани отдельно от этой задачи.

В нашем примере сообщение может выглядеть так: fix(order): validate phone before submitting. Если команда ведёт историю по-русски, подойдёт «Проверять телефон перед отправкой заказа». Главное — чтобы через месяц было понятно, какое поведение изменилось.

Для просмотра уже отобранного содержимого используют git diff --staged. После коммита снова смотрят git status и последнюю запись истории. Чистый статус означает отсутствие текущих несохранённых правок в отслеживаемых файлах; новые неотслеживаемые файлы также нужно учитывать по выводу статуса.

Шаг 5. Передать изменение через PR

После локальной проверки ветку можно отправить на сервер и создать pull request. Для GitHub это выполняется через интерфейс сайта или CLI gh, если он установлен и авторизован. Агенту полезно заранее указать нужный репозиторий и целевую ветку.

Подготовь заголовок и описание PR для текущей ветки относительно согласованной основной ветки. Укажи исходную проблему, новое поведение, проведённые проверки и ограничения. Покажи точный репозиторий назначения и список коммитов. Отправку ветки и создание PR выполни после моего подтверждения этих данных.

Пример описания:

Форма заказа позволяла отправить пустой телефон. Добавлена проверка перед запросом и сообщение у поля. Локально проверены пустой, неверный и корректный номер. Публичный сайт ещё не обновлялся. Серверная проверка входных данных остаётся отдельным уровнем защиты.

Ревьюер сравнивает этот текст с diff, смотрит проверки и проходит пользовательский сценарий. Merge объединяет историю веток. Деплой публикует приложение в нужной среде. В некоторых проектах эти шаги связаны автоматизацией; порядок нужно выяснить по правилам конкретного репозитория.

Что делать с конфликтом

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

Сначала попросите объяснить обе версии и предложить итог. После редактирования прочитайте diff и повторите проверку формы. Исчезновение маркеров конфликта означает только техническую готовность файла к следующему шагу. Смысл изменений подтверждается тестом и пользовательским сценарием.

Если агент предлагает reset --hard, clean -fd, force push или переписывание опубликованной истории, остановитесь и выясните, какие данные будут удалены или изменены. Для отмены уже общего коммита часто подходит отдельный отменяющий коммит через revert; конкретный способ зависит от состояния истории.

Ещё две операции, которые встретятся позже

Stash временно откладывает изменения. Он пригодится при срочном переключении задачи, но перед применением нужно понимать, какие файлы туда попали. Обычный stash и сохранение новых неотслеживаемых файлов различаются; попросите агента перечислить содержимое и способ возврата. После восстановления возможны конфликты.

Cherry-pick переносит выбранный коммит в другую ветку. Например, исправление формы уже есть в разработке и требуется в поддерживаемом релизе. Проверяйте зависимость от предыдущих коммитов: отдельная правка может использовать функцию, которой в релизной ветке ещё нет. Перенос заканчивается проверкой поведения в целевой ветке.

Как понять, что упражнение завершено

У вас должна быть ветка с понятным именем, небольшой проверенный diff, осмысленный коммит и описание PR. Вы можете объяснить, что изменилось в форме и где это проверялось. В выбранных файлах отсутствуют случайные материалы, а существующая работа коллег сохранена.

Повторите этот цикл на ещё одной маленькой задаче. После нескольких повторений Git станет привычным способом держать работу в порядке, а помощь Claude Code будет сводиться к чтению изменений, объяснению команд и аккуратному выполнению согласованных шагов.

Источники

#Инструменты #Практикум #Роман Ботан