Git: история и аккуратная работа с изменениями
Проект робота меняется постепенно: сегодня настроили датчик расстояния, завтра поправили поворот, а через неделю заменили алгоритм объезда препятствия. Без истории трудно вспомнить, какое изменение вызвало ошибку и к какой рабочей версии можно вернуться. Git помогает превратить набор файлов в последовательность осмысленных состояний проекта.
Git — система контроля версий. Она замечает изменения в файлах, позволяет выбрать нужные изменения для сохранения и записывает их в историю как коммиты.
Зачем это нужно
Представим, что мобильный робот уверенно ехал по линии. После настройки коэффициентов он начал колебаться на поворотах. Если старая программа сохранена только как файл final_old_точно_рабочий_2.ino, приходится вручную сравнивать копии и угадывать, что изменилось. В Git можно посмотреть разницу между текущим файлом и последним сохранённым состоянием, найти нужный коммит и восстановить конкретный файл.
Git полезен и в одиночном проекте. Он отвечает на практические вопросы:
- какие файлы изменились после последней проверки робота;
- что именно поменялось в коде или документации;
- какие изменения войдут в ближайший коммит;
- кто и зачем сохранил конкретное решение в командном проекте;
- с какого состояния началась неисправность.
Контроль версий не заменяет испытания. Коммит с сообщением «исправлен датчик» не доказывает, что датчик действительно работает. Зато к коммиту можно привязать проверяемое состояние: код компилируется, датчик измерен на нескольких расстояниях, результаты записаны в журнале проекта.
Как Git используется в этой базе знаний
В этом репозитории Git хранит не только программы, но и методические материалы сайта: Markdown-уроки, изображения, схемы, примеры кода и настройки Docusaurus. Поэтому перед коммитом важно смотреть не только на файлы .ino или .cpp, но и на связанные картинки, ссылки и служебные поля страниц.
| Что изменилось | Что проверить перед коммитом |
|---|---|
текст урока в docs | соседние уроки, последовательность терминов, вопросы самопроверки |
картинка в img/<urok>/ | путь в Markdown, читаемость, соответствие теме статьи |
| пример программы | компиляцию или хотя бы синтаксическую проверку в условиях статьи |
| порядок уроков | sidebar_position и место урока в общей логике раздела |
| описание раздела | _category_.json и страницу индекса раздела |
| команды запуска сайта | README и успешную локальную проверку |
В коммит не должны попадать локальные зависимости и результаты сборки: node_modules, build, .docusaurus, .npm-cache, временные архивы и секретные файлы. Даже если .gitignore уже закрывает такие пути, перед сохранением всё равно используйте git status и git diff --staged.
Главная идея
Git удобно представить как аккуратную инженерную лабораторию с тремя зонами:
рабочая папка -> область подготовки -> история репозитория
редактируем выбираем сохраняем
В рабочей папке лежат файлы, которые вы сейчас меняете. Команда git add помещает выбранное содержимое в область подготовки — её также называют индексом или staging area. Команда git commit записывает подготовленный набор в историю репозитория.
Это промежуточное состояние — главная защита от случайного коммита. Можно изменить код двигателя, черновик отчёта и параметры датчика, но подготовить и сохранить только законченное исправление датчика.
Git хранит историю локально на компьютере. GitHub и другие хостинги могут хранить удалённую копию репозитория и помогать команде обмениваться изменениями. Первые коммиты можно сделать без аккаунта и без подключения к интернету.
Как Git видит файлы
После создания репозитория Git различает несколько состояний. Названия описывают не качество файла, а его отношение к последнему коммиту и области подготовки.
| Состояние | Что оно означает | Следующий осмысленный шаг |
|---|---|---|
| untracked | новый файл ещё не отслеживается | решить, нужен ли он в проекте, затем выполнить git add |
| modified | отслеживаемый файл отличается от последнего коммита | посмотреть разницу командой git diff |
| staged | выбранная версия файла подготовлена к коммиту | проверить git diff --staged и выполнить коммит |
| committed | состояние записано в локальную историю | продолжить работу или передать коммит в удалённый репозиторий |
У одного файла могут одновременно существовать и подготовленные, и более новые рабочие изменения. Например, вы выполнили git add controller.ino, а затем снова отредактировали этот файл. В коммит попадёт подготовленная версия, а последняя правка останется в рабочей папке. Поэтому перед коммитом нужны и git status, и просмотр подготовленной разницы.
Первый локальный репозиторий
Проверьте, что Git установлен:
git --version
Для подписи коммитов задают имя и адрес электронной почты. Эти значения становятся частью метаданных новых коммитов:
git config --global user.name "Имя Фамилия"
git config --global user.email "you@example.com"
Перейдите в папку учебного проекта и создайте репозиторий:
cd line-robot
git init
Внутри появится служебная папка .git. В ней Git хранит историю и настройки репозитория. Не редактируйте её содержимое вручную. Исходные файлы проекта остаются на прежнем месте.
Перед первым добавлением выполните:
git status
Команда показывает текущую ветку, новые и изменённые файлы, а также то, что уже подготовлено. Привычка начинать и заканчивать операцию командой git status снижает риск работы не с тем набором файлов.
Цикл аккуратного коммита
Хороший коммит описывает одно законченное изменение. Для него полезен повторяемый цикл.
1. Посмотреть состояние
git status
Не добавляйте всё автоматически, пока не понимаете список файлов. В проекте могут оказаться результаты сборки, временные журналы или файлы редактора. Для постоянно ненужных путей создают .gitignore; уже отслеживаемый файл одно добавление в .gitignore не перестаёт отслеживать.
2. Посмотреть рабочую разницу
git diff
Эта команда показывает изменения, которые ещё не помещены в область подготовки. Строки со знаком - были удалены, строки со знаком + добавлены. Смотрите не только на правильность кода, но и на случайные отладочные сообщения, изменённые номера выводов и лишние файлы конфигурации.
3. Подготовить конкретные файлы
git add controller.ino README.md
git add не просто включает постоянное слежение за именем файла. Команда помещает в индекс текущее содержимое указанного файла. Если после этого файл снова изменён, новую версию нужно либо добавить ещё раз, либо оставить для следующего коммита.
4. Проверить подготовленный набор
git diff --staged
git status
git diff --staged показывает именно тот патч, который войдёт в ближайший коммит. Если случайный файл уже подготовлен, его можно убрать из индекса, сохранив правки в рабочей папке:
git restore --staged notes.txt
5. Записать коммит
git commit -m "Настроить остановку перед препятствием"
Сообщение отвечает на вопрос «что делает изменение?». Формулировки update, fix или «правки» почти ничего не объясняют. Название «Добавить фильтрацию показаний дальномера» позволит позже отличить этот шаг от изменения скорости моторов.
6. Проверить историю
git log --oneline
Короткий журнал показывает идентификаторы и заголовки коммитов. Подробности выбранного состояния можно посмотреть командой git show <идентификатор>.
Команды как измерительные приборы
| Команда | Что проверяет или меняет | Меняет файлы? |
|---|---|---|
git status | состояния файлов и область подготовки | нет |
git diff | рабочие изменения относительно индекса | нет |
git diff --staged | содержимое будущего коммита | нет |
git add <файл> | помещает выбранное содержимое в индекс | рабочий файл нет, индекс да |
git commit -m "..." | записывает подготовленный снимок в историю | создаёт коммит |
git log --oneline | показывает краткую историю | нет |
git restore <файл> | восстанавливает рабочий файл из индекса | да, несохранённые правки могут исчезнуть |
git restore --staged <файл> | убирает файл из будущего коммита | рабочие правки сохраняются |
Сначала используйте команды наблюдения: status, diff, log. Перед restore, reset, удалением ветки или очисткой файлов остановитесь и определите, какое состояние будет источником восстановления.
Пример: настройка робота, следующего по линии
В репозитории есть controller.ino, схема подключения и таблица испытаний. Ученик меняет коэффициент поворота и одновременно дописывает в README список деталей. Испытание показало, что новый коэффициент помогает, а список деталей пока не проверен.
Разумная последовательность такова:
- Выполнить
git diffи найти строки с коэффициентом. - Подготовить только файл программы:
git add controller.ino. - Проверить будущий коммит:
git diff --staged. - Снова запустить испытание робота.
- Записать коммит с конкретным сообщением, если результат воспроизводится.
- Оставить README в рабочей папке до отдельной проверки.
Получаются два независимых изменения. Если перечень деталей окажется ошибочным, история работающего алгоритма не будет смешана с редактурой документации.
Пример: ветка для рискованного опыта
Для эксперимента с новым алгоритмом поворота можно создать отдельную ветку:
git switch -c experiment-smooth-turn
Коммиты в ней не передвигают основную ветку. Это удобно, когда текущая версия нужна для демонстрации, а эксперимент может занять несколько попыток. Ветка не является резервной копией незакоммиченных файлов: полезные промежуточные состояния всё равно нужно сохранять осмысленными коммитами.
Что запомнить о безопасной истории
- Git записывает подготовленное содержимое, а не все изменения автоматически.
git statusпоказывает состояние, аgit diffпомогает увидеть содержание изменений.- Один коммит проще проверять, если он решает одну задачу.
- Сообщение коммита должно различать инженерные решения, а не просто сообщать о наличии правок.
- Команды восстановления могут удалять несохранённую работу; перед ними проверяют состояние и источник восстановления.
- Для опубликованной общей истории отмену обычно оформляют новым коммитом, а не переписывают уже переданные коммиты.
Практика
Задание 1. История мини-проекта
Создайте папку robot-signal, добавьте файл с псевдокодом включения сигнального светодиода и инициализируйте Git. Сделайте три разных изменения: добавьте условие кнопки, измените время мигания, дополните описание подключения. Разделите их на осмысленные коммиты. Для каждого коммита запишите, какую проверку вы выполнили перед сохранением.
Задание 2. Выбор состава коммита
Одновременно измените два отслеживаемых файла и создайте один новый. Подготовьте только часть изменений. Сравните вывод git diff, git diff --staged и git status. Нарисуйте схему, где находится каждая версия каждого файла.
Задание 3. Безопасная отмена подготовки
Подготовьте файл с помощью git add, затем уберите его из области подготовки без удаления рабочих правок. Проверьте результат двумя командами наблюдения. Не используйте команды с параметром --hard.
Задание 4. Экспериментальная ветка
Создайте ветку для изменения алгоритма робота. Сделайте в ней один коммит, вернитесь в исходную ветку и сравните содержимое файла и вывод журнала. Не объединяйте ветки, пока не сформулируете критерий успешности эксперимента.
Проверьте себя
- Чем рабочая папка отличается от области подготовки?
- Как узнать, какие строки ещё не подготовлены к коммиту?
- Как проверить точное содержимое будущего коммита?
- Почему повторное редактирование файла после
git addтребует новой проверки? - Как убрать файл из области подготовки, не удаляя рабочую правку?
- Почему сообщение «правки» плохо помогает при поиске неисправности?
- Что сохраняет ветка, а что она не сохраняет автоматически?
Сначала ответьте без подсказки. Ответ можно считать полным, если вы:
- формулируете основную мысль своими словами;
- называете важные условия, ограничения или меры безопасности;
- для схемы, кода или расчёта показываете ход решения и ожидаемый результат.
Если один из пунктов объяснить не получается, найдите соответствующую главу статьи, перечитайте её и повторите ответ.
Словарь статьи
- Система контроля версий — инструмент для записи и сравнения состояний файлов проекта.
- Репозиторий — проект вместе со служебными данными и историей Git.
- Рабочая папка — доступные для редактирования файлы текущей версии проекта.
- Область подготовки (индекс) — выбранное содержимое, из которого будет создан следующий коммит.
- Коммит — записанный в историю снимок подготовленного состояния с автором и сообщением.
- Отслеживаемый файл — файл, содержимое которого уже известно Git или подготовлено к коммиту.
- Ветка — подвижная ссылка на линию коммитов, позволяющая развивать вариант проекта отдельно.
- Разница (diff) — построчное представление изменений между двумя состояниями.
- HEAD — ссылка на текущий коммит выбранной ветки.
Связанные темы
- Arduino IDE: первый проект и загрузка скетча — сохранить исходник после успешной компиляции и проверки платы.
- Tinkercad: схема и симуляция без физической платы — фиксировать проверенные варианты виртуальной схемы.
- Visual Studio Code и PlatformIO: структура проекта микроконтроллера — использовать Git в многофайловом проекте.
- ИИ-помощники и GPT: вопросы, проверка и ответственность — проверять предложенные изменения до их добавления в историю.
- Работа с сайтом — как найти статью, пройти практику и сообщить об ошибке.