Проверка состояния в Git - команда git status

Введение

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

Смотрите, я покажу вам, как команда git status помогает контролировать рабочий процесс, какие у нее есть варианты использования и как читать ее вывод без путаницы. Мы разберем разные сценарии: от типичной ежедневной работы до нестандартных ситуаций вроде конфликтов слияния или работы с несколькими ветками.

Цель статьи — сделать так, чтобы вы уверенно ориентировались в выводе git status и могли быстро принимать решения: что добавлять в индекс, что коммитить, что игнорировать и как исправлять типичные проблемы.

Зачем нужна команда git status

Прежде чем переходить к деталям, давайте зафиксируем, что именно показывает git status и почему она так важна.

Команда git status обычно отвечает на такие вопросы:

• Есть ли несохраненные изменения в рабочей директории
• Какие файлы уже добавлены в индекс (staged) и попадут в следующий коммит
• Какие файлы изменены, но пока не добавлены в индекс
• Есть ли новые (неотслеживаемые) файлы
• Есть ли файлы в состоянии конфликта после слияния
• На какой ветке вы сейчас находитесь
• Отстает ли ваша локальная ветка от удаленной или опережает ее

Фактически git status — это ваш "монитор состояния" репозитория. Если вы работаете с Git и не уверены, что происходит, первое, что имеет смысл сделать, — запустить git status.

Базовый синтаксис и варианты вызова

Минимальный вариант

Самый простой и самый частый вариант:

git status

Git выведет полную информацию в "человеко-читаемом" виде: с подсказками и пояснениями. Это удобно, если вы только знакомитесь с Git или хотите видеть подробный текст.

Короткий формат

Если вы уже уверенно работаете с Git и хотите более компактный вывод, используйте:

git status -s
# или
git status --short

Здесь я размещаю пример вывода, чтобы вам было проще понять отличие:

$ git status -s
 M main.py
?? new_file.txt
A  src/new_module.py

Формат -s показывает статус в две колонки:

• первая колонка — состояние файла в индексе (staged)
• вторая колонка — состояние файла в рабочей директории (unstaged)

Об этом мы еще подробно поговорим в отдельном разделе.

Игнорируемые файлы

Иногда вам нужно увидеть, какие файлы игнорируются благодаря .gitignore или другим правилам. Для этого есть флаг:

git status --ignored

Теперь в вывод попадут также ignore-файлы, отмеченные отдельным блоком.

Работа в конкретном подкаталоге

Важно понимать: git status всегда показывает состояние всего репозитория, даже если вы вызываете команду из подкаталога. Но вы можете ограничить вывод конкретным путем.

Например:

git status src/

В этом случае Git покажет состояние только файлов внутри каталога src.

Как читать вывод git status в подробном режиме

Давайте посмотрим типичный вывод git status и разберем его по частям. Представим, что вы работаете в ветке main и немного изменили пару файлов.

$ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   main.py

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        new_script.py

no changes added to commit (use "git add" and/or "git commit -a")

Давайте разберемся на примере, что здесь происходит.

Строка с веткой

On branch main

Здесь Git сообщает, в какой ветке вы сейчас находитесь. Это важно, чтобы понимать, в какую именно ветку вы будете коммитить изменения.

Состояние относительно удаленной ветки

Your branch is up to date with 'origin/main'.

Эта строка показывает, синхронизирована ли ваша локальная ветка с удаленной:

• up to date with — локальная ветка совпадает с origin/main
• ahead of 'origin/main' by N commits — у вас есть N локальных коммитов, которых еще нет на сервере
• behind 'origin/main' by N commits — на сервере есть N коммитов, которых у вас нет
• diverged — у вас и у сервера есть разные новые коммиты, потребуется слияние или rebase

Обратите внимание, что эта информация появляется только если у ветки настроен upstream (обычно создается автоматически при клонировании или при первом push).

Блок "Changes not staged for commit"

Этот блок показывает изменения, которые есть в рабочей директории, но еще не добавлены в индекс (staged).

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   main.py

Здесь:

• modified — файл изменен, но эти изменения еще не попадут в следующий коммит
• подсказка "use git add" напоминает, как добавить файл в индекс
• подсказка "use git restore" говорит, как отменить изменения в рабочей директории

Если вы хотите добавить этот файл к следующему коммиту, используйте:

git add main.py

Если хотите вернуть файл к последней зафиксированной версии:

git restore main.py
# Файл вернется к состоянию HEAD, все незакоммиченные изменения пропадут

Блок "Untracked files"

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        new_script.py

Неотслеживаемые (untracked) файлы — это файлы, которые существуют в рабочей директории, но Git о них пока "не знает":

• они никогда не добавлялись с помощью git add
• они не входят ни в один предыдущий коммит
• часто это новые файлы, которые вы только что создали

Чтобы начать отслеживать такой файл, используйте:

git add new_script.py

Если наоборот, вы не хотите, чтобы Git этот файл видел, добавьте его в .gitignore.

Сообщение "no changes added to commit"

no changes added to commit (use "git add" and/or "git commit -a")

Это резюме: Git сообщает, что в индексе пока нет файлов, подготовленных к коммиту. Изменения есть в рабочей директории, но вы еще не сделали git add.

Состояния файлов и как git status их показывает

Чтобы уверенно понимать вывод git status, полезно четко различать несколько состояний файла.

Основные состояния

Файл в Git может находиться в одном из следующих состояний:

• untracked — неотслеживаемый
• tracked — отслеживаемый (когда-то уже попадал в коммит)
  • unmodified — не изменен с момента последнего коммита
  • modified — изменен в рабочей директории
  • staged — изменения добавлены в индекс и попадут в следующий коммит

Git status как раз и показывает, какие файлы где находятся.

Переходы между состояниями

Покажу вам, как это реализовано на практике, на маленьком примере:

# 1. Создаем новый файл
echo "print('hello')" > app.py

# 2. Проверяем статус
git status
# app.py будет в блоке Untracked files

# 3. Добавляем файл в индекс
git add app.py

# 4. Проверяем статус снова
git status
# app.py теперь в блоке Changes to be committed

# 5. Коммитим файл
git commit -m "Add app.py"

# 6. Еще раз проверяем статус
git status
# Сообщение: nothing to commit, working tree clean

Комментарии к цепочке:

• после создания файла Git видит его как untracked
• после git add файл становится staged
• после git commit файл переходит в состояние tracked и unmodified
• когда вы снова меняете этот файл, он будет marked как modified (и появится в Changes not staged for commit)

Как git status отображает разные состояния

Давайте посмотрим на комбинированный пример:

$ git status
On branch feature/login

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   src/login/form.js
        modified:   src/app.js
        deleted:    src/old_auth.js

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   src/styles.css

Untracked files:
        notes.md

Здесь вы видите три разных типа изменений:

1. Changes to be committed — это staged изменения. Они уже в индексе.

   • new file — новый файл, который уже добавлен
   • modified — измененный и уже добавленный файл
   • deleted — файл удален и это удаление уже зафиксировано в индексе

2. Changes not staged for commit — изменения в tracked файлах, которые вы еще не добавили в индекс.

3. Untracked files — файлы, про которые Git пока ничего не знает.

Если вы сейчас сделаете git commit, в коммит попадут только файлы из блока Changes to be committed.

Короткий формат git status -s

Когда вы часто вызываете git status, полный текст с подсказками может быть избыточным. Для этого есть короткий формат.

Давайте посмотрим, как работает:

$ git status -s
 M main.py
A  src/new_module.py
D  old_config.yml
?? temp.log

Теперь давайте разберемся, что означают эти символы.

Две колонки статуса

В коротком формате каждая строка начинается с двух символов и имени файла:

• первый символ — состояние файла в индексе (staged)
• второй символ — состояние файла в рабочей директории (unstaged)

Это очень важно. Смотрите, я покажу вам структуру:

XY path/to/file

X — индекс (staged)
Y — рабочая директория (unstaged)

Основные символы:

• ' ' (пробел) — нет изменений
• M — modified
• A — added
• D — deleted
• R — renamed
• C — copied
• ? — untracked
• ! — ignored

Примеры комбинаций

Давайте посмотрим, что происходит в следующем примере:

$ git status -s
M  src/app.js      # изменен, добавлен в индекс, в рабочей директории без новых изменений
 M src/api.js      # изменен, но НЕ добавлен в индекс
MM src/core.js     # изменен и в индексе, и в рабочей директории (два разных набора изменений)
A  src/new.js      # новый файл, уже добавлен в индекс
?? notes.txt       # новый файл, неотслеживаемый
 D src/old.js      # файл удален в рабочей директории, но удаление не в индексе
D  src/obsolete.js # файл удален и это удаление уже добавлено в индекс

Обратите внимание:

• строка "M src/app.js" говорит, что в индексе есть изменения (M), а в рабочей директории — нет (пробел)
• строка " M src/api.js" — наоборот, в индексе изменений нет, но рабочая директория содержит изменения
• строка "MM src/core.js" значит, что вы сначала что-то изменили и добавили в индекс (первое M), а потом снова изменили файл (второе M)

Короткий формат с деталями о перемещениях

Если вы часто переименовываете или перемещаете файлы, полезно добавить флаг -M (detect renames):

git status -s -M

В этом случае Git сможет показать R (renamed) вместо комбинации delete + new file, если распознает перемещение.

Пример:

$ git status -s -M
R  src/old_name.js -> src/new_name.js

Git показывает, что файл был переименован, а не просто удален и создан заново.

git status во время слияния и конфликтов

Теперь давайте перейдем к следующему важному сценарию — когда вы делаете merge или rebase, и возникают конфликты. В такие моменты git status становится особенно полезным.

Статус во время слияния

Представим, что вы сделали:

git merge feature/login

и получили конфликты. Вывод git status будет примерно таким:

$ git status
On branch main
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)
        both modified:   src/app.js
        both modified:   src/login/form.js

Untracked files:
        resolve_notes.txt

no changes added to commit (use "git add" and/or "git commit -a")

Здесь важно несколько моментов:

• Git явно говорит: You have unmerged paths — у вас есть неразрешенные конфликты
• блок Unmerged paths показывает файлы в конфликте
• комментарий "use git add to mark resolution" подсказывает, что после ручного разрешения конфликта нужно сделать git add для каждого такого файла

Обозначения конфликтующих файлов в коротком формате

В коротком формате такие файлы будут отмечены комбинациями статусов. Например:

$ git status -s
UU src/app.js
AA src/login/form.js

Где:

• U — unresolved (неразрешенный конфликт)
• AA — файл добавлен в обеих ветках и теперь конфликтует
• UU — файл изменен в обеих ветках и изменения конфликтуют

После того как вы вручную исправили конфликт в файле, используйте:

git add src/app.js
git add src/login/form.js

Теперь git status покажет, что конфликтов нет, и предложит сделать git commit для завершения слияния.

Отмена слияния при помощи информации от git status

Если вы видите в статусе сообщение:

(use "git merge --abort" to abort the merge)

значит, вы можете полностью откатить текущее слияние:

git merge --abort
# Репозиторий вернется в состояние до команды git merge

git status в этом случае выступает как навигатор — он подсказывает доступные действия.

Состояние ветки: отставание и опережение

В ежедневной работе с удаленными репозиториями важно понимать, насколько ваша ветка синхронизирована с сервером.

Что показывает git status

Пример вывода:

$ git status
On branch main
Your branch is ahead of 'origin/main' by 2 commits.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean

Расшифровка:

• ahead by 2 commits — у вас есть два локальных коммита, которых нет на сервере
• Git предлагает использовать git push

Другой вариант:

$ git status
On branch main
Your branch is behind 'origin/main' by 3 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)

Здесь:

• behind by 3 commits — на сервере есть три новых коммита
• can be fast-forwarded — вашу ветку можно просто "подвинуть" вперед

И еще один вариант:

$ git status
On branch main
Your branch and 'origin/main' have diverged,
and have 2 and 3 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)

В этом случае у вас и у сервера есть свои новые коммиты, и при git pull произойдет слияние или rebase (в зависимости от настроек).

Как обновить ветку, ориентируясь на git status

Если ветка:

• ahead — используйте git push

git push

• behind или diverged — используйте git pull (или более аккуратный вариант с rebase):

# стандартный вариант
git pull

# вариант через rebase
git pull --rebase

После этого git status снова покажет up to date.

Взаимодействие git status с индексом и рабочей директорией

Чтобы git status не казался "магией", полезно связать его с базовой моделью Git: индекс, рабочая директория, последний коммит (HEAD).

Три "слоя" состояния

Представьте, что у файла есть три версии:

• версия в HEAD — состояние файла в последнем коммите
• версия в индексе (staging area) — то, что подготовлено к следующему коммиту
• версия в рабочей директории — то, что лежит у вас на диске прямо сейчас

Состояние файла, которое вы видите в git status, — это результат сравнения этих трех версий.

Давайте посмотрим маленький пример:

# 1. Последний коммит
# app.py содержит строку: print("v1")

# 2. Меняем файл и добавляем в индекс
echo 'print("v2")' > app.py
git add app.py

# 3. Опять меняем файл, но уже после git add
echo 'print("v3")' > app.py

git status -s

Ожидаемый вывод:

MM app.py

Пояснение:

• индекс (первая M) содержит версию v2
• рабочая директория (вторая M) содержит версию v3
• HEAD содержит версию v1

Если вы сейчас сделаете git commit, в коммит попадет версия v2 (то, что в индексе), а не v3. Это важный момент, который git status в коротком формате хорошо подчеркивает.

Как с помощью git status контролировать индекс

Допустим, вы случайно добавили в индекс не тот файл. Git status подскажет вам и подскажет команду для исправления.

Пример:

$ git status
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   config.yml
        modified:   large_tmp.json

Если вы не хотите коммитить large_tmp.json, сделайте:

git restore --staged large_tmp.json

Теперь:

• config.yml останется staged
• large_tmp.json вернется в состояние "изменен в рабочей директории", но не staged

git status после этого отразит новую картину.

Полезные флаги и опции git status

Давайте соберем в одном месте несколько опций, которые будут полезны в реальной работе.

--short и --branch

Вы уже видели -s / --short. Часто его комбинируют с -b для показа информации о ветке:

git status -sb

Пример вывода:

$ git status -sb
## main...origin/main [ahead 1]
 M src/app.js
?? notes.txt

Разбор:

• строка "## main...origin/main [ahead 1]" показывает:
  • текущую ветку main
  • связанный remote-branch origin/main
  • состояние ahead/behind

--ignored

Если вам нужно увидеть игнорируемые файлы:

git status --ignored

Пример:

$ git status --ignored
On branch main

Ignored files:
  (use "git add -f <file>..." to include in what will be committed)
        logs/
        tmp/
        .env.local

Это полезно, когда вы проверяете, правильно ли настроен .gitignore.

Ограничение по пути

Вы не обязаны смотреть статус всего репозитория сразу. Можно сузить область:

git status src/
git status src/components/Button.js

В таком случае Git покажет статус только указанных файлов или каталогов. Это удобно в больших монорепозиториях.

--porcelain (для скриптов)

Если вы пишете скрипты, которые анализируют состояние репозитория, есть специальный режим:

git status --porcelain

Он похож на короткий формат, но с гарантированно стабильным машинно-читаемым форматом. Для ручной работы он выглядит почти так же, но в автоматизации этот режим очень полезен.

Типичные сценарии использования git status

Теперь давайте кратко пройдемся по типичным ежедневным сценариям и посмотрим, как git status помогает вам контролировать ситуацию.

Перед началом работы

Перед тем как менять код, стоит убедиться, что у вас чистое состояние:

git status

Идеальный вариант:

nothing to commit, working tree clean

Если вы видите незакоммиченные изменения, есть смысл сначала завершить начатую работу (сделать git add + git commit или отменить изменения), а уже потом переключаться на новые задачи.

Перед переключением ветки

Важно: Git не позволит вам легко переключиться на другую ветку, если у вас есть конфликты по файлам. Команда git status перед git switch / git checkout помогает избежать сюрпризов.

Пример:

git status
# если есть изменения, решите, что с ними делать
git switch feature/new-api

Если вы попытаетесь переключиться и получите ошибку, git status как раз покажет, какие файлы мешают.

Во время разработки

Обычно разработчики несколько раз за рабочий час смотрят git status, чтобы:

• убедиться, что добавили в индекс все нужные файлы
• проверить, не забыли ли о новых файлах
• увидеть, что случайно не добавили лишний файл в staged

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

# Вы что-то меняете в коде
git status               # смотрите, что изменено
git add src/app.js       # добавляете нужные файлы
git status               # проверяете, что именно попадет в коммит
git commit -m "Implement feature X"
git status               # убеждаетесь, что рабочее дерево чистое

При появлении конфликтов

Во время merge, rebase, cherry-pick git status становится "панелью управления":

• показывает конфликтующие файлы
• подсказывает, какие команды доступны (git merge --abort, git rebase --abort и т.д.)
• помогает убедиться, что вы разрешили все конфликты перед завершением операции

После каждого шага разрешения конфликтов полезно делать git status, чтобы видеть прогресс.

Заключение

Команда git status — это основной инструмент контроля состояния репозитория в Git. Она помогает понять:

• какие файлы изменены и в каком они состоянии (staged, unstaged, untracked)
• какие изменения попадут в следующий коммит
• есть ли конфликты и что с ними делать
• как ваша локальная ветка соотносится с удаленной

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

Используя комбинацию подробного и короткого форматов, а также дополнительные флаги (–short, –branch, –ignored, ограничение по пути), вы можете настроить вывод под свой стиль работы и быстро ориентироваться даже в больших проектах.

Частозадаваемые технические вопросы по теме статьи и ответы на них

Как сделать так, чтобы git status не показывал определенные новые файлы

Если вы постоянно видите в Untracked files временные файлы или артефакты сборки, добавьте их в .gitignore:

# Откройте или создайте файл .gitignore в корне репозитория
echo "dist/" >> .gitignore    # игнорируем каталог dist
echo "*.log" >> .gitignore    # игнорируем все .log файлы

# Проверьте статус снова
git status

Если файл уже отслеживается, перед игнором нужно удалить его из индекса:

git rm --cached path/to/file

Почему git status показывает изменения, хотя файл я не менял

Частая причина — изменения только в переводе строк (CRLF vs LF) или в правах доступа. Проверьте:

git diff

Если видите только изменения в переводе строк, настройте autocrlf:

git config core.autocrlf true     # для Windows
git config core.autocrlf input    # для Unix похожих систем

Затем нормализуйте файл и пересоздайте коммит.

Как увидеть разницу только для файлов из блока "Changes not staged for commit"

Используйте git diff без параметров — он как раз показывает изменения в рабочей директории относительно индекса:

git status
git diff        # только unstaged изменения

Для staged изменений используйте:

git diff --cached

Как узнать, какие файлы изменены на уровне прав доступа (mode), а не контента

Короткий формат git status сам по себе не показывает изменение прав. Чтобы его увидеть, воспользуйтесь:

git diff --summary

или смотрите подробный diff:

git diff
# В заголовке патча будет указано изменение режима файла

Как использовать git status в скрипте для проверки "чистоты" репозитория

Лучше использовать машинный формат:

if [ -n "$(git status --porcelain)" ]; then
  echo "Есть незакоммиченные изменения"
  exit 1
fi

Здесь git status --porcelain вернет пустую строку, если рабочее дерево чистое. Это удобно в CI перед сборкой или релизом.