Три зоны: working tree, индекс, репозиторий

Зона в Git - это место, где хранится какая-то версия твоих файлов. Их три:

1. Working tree (рабочее дерево) - твои файлы на диске, те самые, которые ты правишь в редакторе.
2. Index (индекс, он же staging area) - промежуточное место, где Git собирает следующий коммит. Двоичный файл .git/index.
3. Repository (репозиторий) - то, что закоммичено. Объекты в .git/objects/, на которые указывают ветки в .git/refs/.

Любая команда Git, которая что-то делает с твоими файлами, двигает их между этими зонами. Иногда добавляет, иногда забирает, иногда сравнивает. Поэтому первый вопрос про каждую команду - «с какими зонами она работает».

working tree   ──→  индекс  ──→  репозиторий

      ↑                              │

      └──────────────────────────────┘

                   checkout

Стрелка от working tree вправо - это git add. От индекса вправо - git commit. Стрелка обратно - git checkout или git restore.

Working tree - то, что ты видишь в редакторе. Файлы, директории, права доступа. Git к ним не привязан напрямую: он просто лежит рядом в .git/, наблюдает и при команде что-то делает.

Git не отслеживает файлы автоматически. Изменения нужно явно отправить в индекс. Это значит:

• Создал новый файл - он untracked, Git ничего о нём не знает.
• Изменил отслеживаемый файл - он modified, но изменения пока только в рабочем дереве.
  • Удалил файл - Git это увидит как deleted, но удаление тоже надо застейджить.

Все три состояния показывает git status. Раздел «Untracked files» - это пункт 1, «Changes not staged for commit» - пункты 2 и 3.

Работа с working tree - это работа в любом текстовом редакторе или IDE. Git туда вмешивается только когда явно попросишь - через checkout, restore, reset --hard.

Индекс - самая необычная часть Git. В других VCS его обычно нет: ты редактируешь файлы и сразу коммитишь. В Git между «редактируешь» и «коммитишь» есть промежуточный шаг - выбрать, что именно пойдёт в коммит.

Физически индекс - это двоичный файл .git/index. В нём для каждого отслеживаемого пути записано:

• имя файла,
• права доступа,
• SHA blob'а с содержимым,
• метаданные stat-а файла (для быстрого определения изменений).

Когда мы говорим «застейджить» (git add), это означает: прочитать файл из рабочего дерева, создать blob, обновить запись в индексе.

Один из частых вопросов про индекс - «зачем он вообще». Ответ приходит, когда работаешь над чем-то сложным:

• Поправил два не связанных бага в одном файле. Хочется закоммитить их отдельно. git add -p позволяет застейджить часть изменений из файла.
• Сделал большую правку, но один файл ещё не готов. Стейджишь всё кроме него, коммитишь чистую часть, дорабатываешь второй отдельно.
• Готовишь несколько коммитов, но не хочется их сразу пушить. Каждый раз стейджишь нужный подмножество, коммитишь, повторяешь.

Без индекса каждый коммит - это снимок всего, что лежит в рабочем дереве. С индексом - снимок того, что выбрал.

Команды для работы с индексом:

• git add <path> - добавить файл (или директорию) в индекс.
• git add -p - интерактивно, по hunk'ам.
• git rm --cached <path> - убрать из индекса, но оставить в рабочем дереве.
  • git restore --staged <path> - откатить стейдж конкретного файла (то, что раньше делал git reset HEAD <path>).

Слово «индекс» в Git перегружено. Помимо staging area, оно же используется как:

• кэш состояния рабочего дерева - для ускорения git status. Без индекса Git каждый раз пересчитывал бы SHA каждого файла, чтобы понять, изменился ли он.
  • рабочая зона merge - при конфликте слияния в индексе для каждого конфликтного файла лежит три версии (base, ours, theirs). Это --ours, --theirs, --base варианты в git checkout.
• хранилище для git stash. Хотя stash сейчас сделан через отдельные коммиты, исторически он жил в индексе.

Поэтому в документации можно встретить «index», «cache» (старое имя), «staging area» - это всё про один и тот же .git/index. В скриптах исторически осталось --cached (git rm --cached, git ls-files --cached) - синоним для «работа с индексом».

Самая полезная картинка для отладки запутанных ситуаций - таблица «команда × зона». В каждой ячейке - что команда делает с этой зоной.

Если запомнить три зоны и заглядывать в эту таблицу при сомнении - команды Git перестают казаться непредсказуемыми. Большая часть путаницы возникает из-за того, что одна команда (например, reset) при разных флагах трогает разное количество зон.

git diff - это команда «покажи разницу между двумя версиями». Версии могут лежать в разных зонах. Поэтому у git diff четыре основных режима, по одному на каждую интересную пару зон.

git diff

Сравнивает working tree с индексом.

Это «что я ещё не застейджил». Если ты поправил файл, но не сделал git add - git diff покажет твою правку. Если застейджил всё - выведет пустоту.

git diff --staged (или --cached)

Сравнивает индекс с HEAD.

Это «что войдёт в следующий коммит». Если ничего не стейджил - пусто. Если застейджил - увидишь именно те изменения, которые попадут в git commit.

git diff HEAD

Сравнивает working tree с HEAD.

Это «всё, что отличается от последнего коммита» - независимо от того, застейджено или нет. Сумма первых двух.

git diff <commit-A> <commit-B>

Сравнивает два коммита в репозитории.

Working tree и индекс не участвуют. Это удобно для просмотра, что изменилось между релизами, в feature-branch, между тегами: git diff v1.0 v2.0.

Все варианты можно сужать конкретными путями:

git diff HEAD -- src/api.ts

git diff main feature -- backend/

Шорткаты, которые экономят время:

• git diff --stat - только сводка (файлы и количество строк).
• git diff -w - игнорировать изменения в whitespace.
• git diff --word-diff - построчно показать изменения по словам, не по строкам. Удобно для текстов и markdown.

Несколько частых ситуаций становятся прозрачными, если думать зонами.

«Я случайно сделал git add и хочу откатить стейдж».

Файл переехал из working tree в индекс. Откатить = вернуть индекс к состоянию HEAD. Это git restore --staged <file>. Working tree не трогаем.

«Я закоммитил, а потом понял что хочу добавить ещё один файл в этот же коммит».

Стейдж файл (git add), потом git commit --amend. amend берёт текущее состояние индекса и переписывает HEAD-коммит. Working tree не двигается, репозиторий получает новый коммит на месте старого (старый становится висячим).

«Я хочу временно убрать незакоммиченные правки, чтобы переключить ветку».

git stash - забирает working tree и индекс в специальный stash-коммит, чистит working tree до HEAD. После переключения ветки и работы - git stash pop возвращает обратно.

«Я хочу полностью откатить рабочую копию до состояния последнего коммита».

git reset --hard HEAD. Жёсткий вариант - переписывает все три зоны до HEAD. Утратишь незакоммиченные правки безвозвратно. Перед этим - git stash на всякий случай, если не уверен.

«Я случайно сделал git reset --hard и хочу вернуть состояние».

Если коммит был - git reflog покажет SHA состояния «до». git reset --hard <тот-SHA> вернёт ветку. Если правки не были закоммичены - увы, рабочее дерево потеряно. Это и есть тот случай, когда коммитить часто - выгодно.

«Файл по ошибке попал в git, надо убрать из репозитория, но оставить на диске».

git rm --cached <file> + добавить в .gitignore + закоммитить. Файл уйдёт из индекса (и из следующего коммита), но останется в рабочем дереве. Из истории при этом он не пропадёт - для этого нужен git filter-repo, тема отдельная.

git reset <commit> - самая опасная команда из часто используемых. У неё три флага, и разница принципиальная.

• --soft - самый безопасный. Передвигает только ветку, всё остальное остаётся как было. Использование: «хочу переделать последний коммит, оставив правки в индексе».
  • --mixed - по умолчанию. Двигает ветку и переписывает индекс. Working tree остаётся как есть. Использование: «отменить несколько коммитов, оставив изменения как unstaged».
  • --hard - переписывает всё. Незакоммиченные правки теряются. Использование: «полностью откатить состояние, потери не страшны».

--hard особенно коварен на новых ветках, у которых нет аналога в reflog. Если хочешь подстраховаться - сделай тег или ветку перед reset: git tag backup-before-reset. Потом тег легко удалить, а если что-то пошло не так - откатиться обратно.