Терминал, Git и первое изменение
Рабочий каталог — часть входа команды. pnpm в корне и в infra/strapi
работает с разными проектами; одинаковое имя файла не делает их взаимозаменяемыми.
Перед командой проверьте pwd. Относительный путь считается от этого каталога.
ls показывает содержимое, cd меняет каталог, .. обозначает родителя.
Кавычки сохраняют путь с пробелами как один аргумент. Код завершения 0 означает
успех команды, другой код — повод прочитать ошибку; он не доказывает правильность результата.
Три состояния файла
Git хранит снимки проекта. Рабочий файл, индекс будущего коммита и последний
коммит могут содержать три разные версии. git diff сравнивает рабочий файл
с индексом, git diff --cached — индекс с HEAD. Ветка — перемещаемое имя коммита,
worktree — отдельный каталог с выбранной веткой. Это позволяет изучать проект,
не переключая checkout другого человека.
Исходник схемы
flowchart LR File[Рабочие файлы] -->|git add путь| Index[Индекс] Index -->|git commit| Commit[Снимок] Commit --> Branch[Ветка указывает на снимок]
git status --short --branch — первая команда перед изменениями. Не считайте
неизвестный diff своим и не добавляйте всё содержимое каталога автоматически.
git restore и git reset способны потерять работу: для знакомства они не нужны.
Создать учебное рабочее дерево
Сначала получите репозиторий
и войдите в ~/projects/gheilt. Затем из основного checkout,
с уникальным именем ветки и каталога:
git status --short --branch
git worktree list
git rev-parse --git-dir --git-common-dir --show-superproject-working-tree
git check-ignore .worktrees
git worktree add -b learning/first-change .worktrees/first-change HEAD
cd .worktrees/first-change
pwd
pnpm install --frozen-lockfile
Продолжайте только если .worktrees исключён из Git. HEAD здесь выбирает
текущий снимок; для работы над другой задачей сначала согласуйте базовый commit.
В Arcadia вместо этих команд действует отдельный инструмент arc-wt.
Первый цикл: небольшой текстовый diff
Найдите в docs/practice/learning.md контрольный вопрос и уточните его формулировку,
не меняя команды и поведение приложения. Сначала прочитайте связанный ответ
в соответствующей главе. Это упражнение на точность, а не на количество правок.
git diff -- docs/practice/learning.md
pnpm exec oxfmt --check docs/practice/learning.md
pnpm --filter @atmanki/docs test
git diff --check
git add docs/practice/learning.md
git diff --cached
git commit -m "docs: clarify learning question"
Для исправления формата используйте pnpm exec oxfmt docs/practice/learning.md
и перечитайте diff. Тест документации проверяет ссылки и состав глав; он
не проверяет педагогическую ценность нового текста. Изменение API дополнительно
требовало бы серверного теста, изменение типов — typecheck затронутого пакета.
Состав проверок выбирается по изменённому контракту.
Результат: один коммит с одной объяснимой правкой. Запишите базовый и новый
commit через git rev-parse HEAD. Покажите diff человеку, который не видел
вашей работы: он должен понять причину без переписки.
Слияние и публикация — отдельный этап. Не пушьте учебную ветку в main,
чтобы посмотреть, что произойдёт: у проекта есть настоящий deploy workflow.
Чистый ненужный worktree удаляют из другого каталога через git worktree remove;
ветку сохраняют, пока коммит не интегрирован. Не применяйте --force к своей
незаконченной работе.
Конфликт как задача согласования
Если две ветки меняют одну формулировку, Git не знает намерение автора. Прочитайте обе версии и контекст, составьте итоговую формулировку, удалите маркеры конфликта и повторите связанные проверки. Выбор «нашей версии» целиком не является разбором конфликта. Не переписывайте историю чужой ветки.
Упражнение: нарисуйте рабочий файл, индекс и HEAD после изменения текста,
после git add и после дополнительного изменения. Предскажите оба diff до запуска.
Источники: основы Git, worktree.