Git -- рабочая директория, staging area, репозиторий

Git делит работу с файлами на три зоны: рабочая директория (где ты редактируешь), staging area (что войдёт в следующий коммит) и репозиторий (история всех коммитов).

Зачем нужно

Понимание трёх зон объясняет, почему Git работает именно так. Staging area даёт контроль: можно изменить 10 файлов, но закоммитить только 3 — те, что относятся к одной задаче. Без этого понимания команды git add, git status, git diff кажутся магией.

Где используется

  • Ежедневный цикл разработки: edit → add → commit
  • Разбиение большого изменения на логические коммиты
  • Проверка что именно войдёт в коммит до его создания

Основной контент

Три зоны Git

┌─────────────────────────────────────────────────────────┐
│               Рабочая директория                        │
│         (Working Directory / Working Tree)              │
│    Файлы, которые ты видишь и редактируешь              │
└──────────────────────┬──────────────────────────────────┘
                       │ git add
                       ▼
┌─────────────────────────────────────────────────────────┐
│                  Staging Area                           │
│              (Index / Cache)                            │
│    Файлы, подготовленные для следующего коммита         │
└──────────────────────┬──────────────────────────────────┘
                       │ git commit
                       ▼
┌─────────────────────────────────────────────────────────┐
│                  Репозиторий                            │
│              (.git директория)                          │
│    Постоянная история всех коммитов                     │
└─────────────────────────────────────────────────────────┘

Статусы файлов

git status

Файл в рабочей директории может быть:

  • Untracked — новый файл, Git не отслеживает
  • Modified — изменён по сравнению с последним коммитом
  • Staged — добавлен в staging area (готов к коммиту)
  • Unmodified — не изменён

Команды для работы с зонами

# Добавить файл в staging area
git add file.js          # конкретный файл
git add src/             # вся папка
git add .                # все изменения в текущей папке
git add -p               # интерактивно: выбирать куски изменений

# Убрать из staging area (unstage)
git restore --staged file.js   # современный способ
git reset HEAD file.js         # старый способ

# Просмотр различий
git diff              # рабочая директория vs staging area
git diff --staged     # staging area vs последний коммит
git diff HEAD         # рабочая директория vs последний коммит

# Проверка статуса
git status            # полный вывод
git status -s         # краткий вывод (M = modified, A = added, ? = untracked)

Пример рабочего цикла

# 1. Изменили два несвязанных файла
git status
# Modified: auth.js
# Modified: style.css

# 2. Добавляем только первый (они разные задачи)
git add auth.js
git status
# Staged:   auth.js
# Modified: style.css

# 3. Делаем коммит только для auth.js
git commit -m "fix: исправить проверку токена"

# 4. Добавляем второй
git add style.css
git commit -m "style: обновить кнопки"

Сброс изменений

# Отменить изменения в рабочей директории (опасно!)
git restore file.js        # вернуть файл к состоянию staging area / последнего коммита

# Убрать файл из staging area
git restore --staged file.js

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

  • git add . всегда — добавляет всё подряд; лучше добавлять конкретные файлы или использовать git add -p для контроля
  • Не проверять git diff --staged — коммитят то, что не собирались; всегда смотри, что именно в staging area
  • Путаница git diff и git diff --staged — первый показывает незастейженные изменения, второй — застейженные

Связанные темы

Ресурсы