Что означает неотслеживаемый статус файла в выводе команды git status

Обновлено: 21.11.2024

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

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

Обзор статуса Git

Вот как выглядит команда git status:

Его можно запустить внутри проекта, в котором инициализирован репозиторий Git. Итак, давайте также создадим новый проект, в котором мы сможем изучить эту команду состояния:

$ mkdir git-status && git init
Инициализирован пустой репозиторий Git в формате . /git-статус/.git/

Это мост

По сути, команда git status образует мост между командами добавления и фиксации. Первый добавляет ваши изменения или файлы в тестовую область, а второй фиксирует эти изменения в истории коммитов.

Мы знаем, что Git работает с тремя разными деревьями: рабочим каталогом, промежуточной областью и историей коммитов. Если вы не знакомы с этими концепциями, вы можете узнать о них больше здесь. Команда состояния в основном работает с первыми двумя деревьями: рабочим каталогом и промежуточной областью.

Что на самом деле говорит нам команда состояния?

Команда git status сообщает вам три важные вещи:

Какие изменения вы внесли в свой рабочий каталог

Изменения в вашей тестовой области

Какие из ваших файлов на самом деле отслеживаются Git

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

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

Неотслеживаемое состояние

Давайте начнем с создания трех пустых текстовых файлов внутри нашего проекта.

$ echo > файл1.txt > файл2.txt > файл3.txt

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

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

Теперь давайте запустим команду состояния:

$ git status
На мастере ветки

Неотслеживаемые файлы:
(используйте "git add . ", чтобы включить в то, что будет зафиксировано)
file1.txt
file2.txt
file3.txt

для фиксации ничего не добавлено, но присутствуют неотслеживаемые файлы (используйте "git add" для отслеживания)

Обратите внимание, что Git указывает, что все ваши файлы не отслеживаются. Это неотслеживаемое состояние в основном представляет файлы или изменения, которые Git еще не отслеживает. Все файлы вашего проекта находятся в этом состоянии, когда вы впервые инициализируете репозиторий Git. Таким образом, буква U, о которой мы говорили ранее, означает не отслеживается.

Вы можете удалить файлы из неотслеживаемого состояния, выполнив команду добавления. На этом этапе Git знает, что ему нужно отслеживать эти новые файлы.

Допустим, мы хотим отслеживать файл1 и файл2. Запустите команду добавления для этих двух файлов:

$ git добавить файл1.txt файл2.txt

Теперь, если мы запустим команду git status:

$ git status
На мастере ветки

Изменения, которые нужно зафиксировать:
(используйте "git rm --cached . ", чтобы отменить стадию)
новый файл: file1.txt
новый файл: file2.txt

Неотслеживаемые файлы:
(используйте "git add . ", чтобы включить в то, что будет зафиксировано)
file3.txt

Git сообщает нам, что отслеживаются и файл1, и файл2, и только файл3 остается неотслеживаемым. Выполнив команду состояния, вы можете проверить свои неотслеживаемые файлы и переместить их в промежуточную область, чтобы Git мог отслеживать изменения в этих файлах.

Но почему мы оставили файл 3? Давайте рассмотрим это сейчас.

Состояние отсутствия истории

Иногда ваш проект содержит файлы, которые вы не хотите отслеживать с помощью Git. Это могут быть скомпилированные двоичные файлы вашего проекта, внешние зависимости, файлы .env или среды, содержащие конфиденциальные учетные данные, и т. д. Вы можете сохранить эти файлы в состоянии отсутствия истории, добавив их записи в специальный файл .gitignore, чтобы Git никогда их не отслеживал.

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

Откройте этот проект в редакторе и создайте файл .gitignore. Добавьте файл file3.txt в файл .gitignore, как показано ниже:

Все файлы выделены зеленым цветом, кроме файла 3, который выделен серым цветом. Все файлы, которые вы добавляете в файл .gitignore, выделяются серым цветом.

Обратите внимание, что после файла .gitignore стоит буква U, что означает, что сам этот файл находится в неотслеживаемом состоянии. Давайте проверим это, выполнив команду git status:

$ git status
На мастере ветки

Неотслеживаемые файлы:
(используйте "git add . ", чтобы включить в то, что будет зафиксировано)
.gitignore

Мы можем подтвердить, что файл file3 был удален из неотслеживаемого состояния, а файл .gitignore находится в неотслеживаемом состоянии. Итак, давайте сейчас запустим команду add, так как мы хотим, чтобы Git отслеживал ее:

$ git добавить . && статус git
На мастере ветки

Вносимые изменения:
(используйте «git rm --cached . », чтобы отменить стадию)
новый файл: .gitignore
новый файл: file1.txt
новый файл : файл2.txt

Отлично! Теперь у вас нет ничего в неотслеживаемом состоянии, и вы перевели конфиденциальный файл вашего проекта в состояние отсутствия истории.

Измененное состояние

Неотслеживаемые файлы предназначены для отслеживания их в какой-то более поздний момент времени. Ранее мы переместили наши файлы file1 и file2 из неотслеживаемого состояния с помощью команды add. Но что случилось с этими файлами и где они сейчас?

Допустим, теперь мы хотим изменить содержимое обоих этих файлов.

Обратите внимание, что и файл1, и файл2 выделены оранжевым цветом и сопровождаются буквой М, а не буквой А. Эта буква М означает «изменено». Поэтому эти файлы теперь находятся в измененном состоянии.

Теперь запустим команду git status:

$ git status
На мастере ветки

Изменения, не подготовленные для фиксации:
(используйте "git add . ", чтобы обновить то, что будет зафиксировано)
(используйте "git restore . ", чтобы отменить изменения в рабочем каталоге)
изменено : файл1.txt
изменено: файл2.txt

Измененное состояние в основном сообщает вам, какие изменения готовы к фиксации. Мы изменили файл1 и файл2 и перевели их в измененное состояние.

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

Передача параметров в команду состояния

До сих пор мы напрямую использовали только команду состояния. Однако вы также можете передать ему параметры или флаги. Например, вы можете отобразить все игнорируемые файлы или файлы, находящиеся в состоянии отсутствия истории, используя флаг --ignored.

$ git status --ignored
На мастере ветки

Игнорируемые файлы:
(используйте "git add -f . ", чтобы включить в то, что будет зафиксировано)
file3.txt

Помните, мы добавили файл 3 в состоянии отсутствия истории? Мы можем увидеть это под заголовком «Игнорируемые файлы» в выводе команды git status, как показано выше.

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

$ git status -s
A .gitignore
AM file1.txt
AM file2.txt

Буква рядом с каждым из этих файлов показывает их текущее состояние в вашем проекте. Все файлы в промежуточной области имеют перед собой букву А. Поскольку мы переместили файлы file1 и file2 в измененное состояние, перед ними также стоит буква M.

Вот исчерпывающий список параметров, которые вы можете передать команде git status.

Журнал Git и статус Git

Мы видели, что git status отображает состояние рабочего каталога и промежуточной области. Команду git status часто сравнивают и иногда путают с другой похожей командой, называемой командой git log.

Как следует из названия, git log отображает журнал информации, но эта информация относится только к вашей истории коммитов. Таким образом, он просто отображает список коммитов, которые вы внесли в свой проект.

Сейчас сделаем несколько коммитов в нашем проекте.

$ git добавить . && git commit -m "modified file1 and file2"
[master (root-commit) d54f32e] измененный file1 и file2
изменено 3 файла, 3 вставки(+)
режим создания 100644 .gitignore
создать режим 100644 file1.txt
создать режим 100644 file2.txt

Git сообщает нам ветку, в которой мы находимся, небольшой хэш сгенерированного нами коммита и переданное нами сообщение коммита. Давайте проверим историю коммитов, выполнив команду git log:

$ git log
commit d54f32e2dc7d36a71c33e965368f292e7895c262 (HEAD -> master)
Автор: fuzzysid
Дата: вторник, 19 октября, 09:01:08 2021 +0530

измененный файл1 и файл2

Вы также можете понимать git log как эквивалент состояния git, но только для ваших зафиксированных изменений. Вот исчерпывающий список общих параметров, которые вы можете передать в дополнение к команде git log.

Git Diff и Git Status

Команда git diff часто используется в сочетании с git status для анализа изменений в вашем файле. Так же, как и команда git log, это общая причина непонимания и путаницы для разработчиков.

Команда git diff предоставляет более подробную информацию о состоянии ваших файлов. Само слово «Diff» означает difference, а git diff предоставляет вам точные изменения в ваших файлах.

Вернемся к нашим предыдущим примерам и изменим содержимое файла file1. В настоящее время file1 содержит простое приветствие внутри.

Давайте заменим "привет" на что-нибудь другое:

Обратите внимание, что файл file1 теперь находится в измененном состоянии. Давайте теперь запустим команду git diff:

$ git diff
diff --git a/file1.txt b/file1.txt
index b6fc4c6..6411ab1 100644
--- a/file1.txt
+++ b/file1.txt
@@ -1 +1,2 @@
-hello
\ Нет новой строки в конце файла
+Содержимое изменено
+Проверка различий
\ Нет новой строки в конце файла

Таким образом, команда git diff сообщает вам точные изменения, внесенные в файлы, вместе с некоторой другой метаинформацией. В приведенном выше выводе мы видим, что в файле file1 произошли некоторые вставки и удаления. Мы также видим, что было удалено и что добавлено построчно.

В то время как git status показывает только состояние изменений вашего файла, git diff сообщает вам точные изменения. Вы можете использовать git diff для сравнения ваших изменений перед промежуточным размещением или фиксацией. Вы также можете использовать эту команду с флагом --color-words для визуального выделения изменений:

Вот так! Теперь ваши удаления отмечены красным, а вставки — зеленым.

Заключение

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

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

Наконец, используйте команду git log, чтобы просмотреть все ваши коммиты, прежде чем отправлять их в удаленный репозиторий. Это обеспечит аккуратное использование Git и позволит вашим товарищам по команде избежать путаницы в отношении изменений, внесенных вами в проект.

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

Установка и настройка

Получение и создание проектов

Базовый снимок

Ветвление и слияние

Обмен проектами и их обновление

Осмотр и сравнение

Исправление

Отладка

Электронная почта

Внешние системы

Администратор сервера

Руководства

Администрирование

Связные команды

Проверьте свою версию git, запустив

git-status — Показать статус рабочего дерева

ОБЗОР

ОПИСАНИЕ

Отображает пути с различиями между файлом индекса и текущим коммитом HEAD, пути с различиями между рабочим деревом и файлом индекса, а также пути в рабочем дереве, которые не отслеживаются Git (и не игнорируются gitignore). [5]). Первые — это то, что вы зафиксируете, запустив git commit ; второе и третье — это то, что вы можете зафиксировать, запустив git add перед запуском git commit .

ВАРИАНТЫ

Предоставьте результат в сокращенном формате.

Показывать ветку и информацию об отслеживании даже в сокращенном формате.

Показать количество спрятанных записей.

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

Параметр версии используется для указания версии формата. Это необязательно и по умолчанию используется формат исходной версии v1.

Предоставьте вывод в длинном формате. Это значение по умолчанию.

В дополнение к именам файлов, которые были изменены, также отображайте текстовые изменения, подготовленные для фиксации (например, вывод команды git diff --cached ). Если -v указан дважды, то также показать изменения в рабочем дереве, которые еще не были подготовлены (т. е. как вывод git diff ).

Показать неотслеживаемые файлы.

Параметр режима используется для указания обработки неотслеживаемых файлов. Это необязательно: по умолчанию используется значение all, и если оно указано, оно должно быть привязано к параметру (например, -uno , но не -u no ).

no — не показывать неотслеживаемые файлы.

обычный — показывает неотслеживаемые файлы и каталоги.

все – также показывает отдельные файлы в неотслеживаемых каталогах.

Если параметр -u не используется, отображаются неотслеживаемые файлы и каталоги (т. е. так же, как при указании normal ), чтобы вы не забыли добавить вновь созданные файлы. Поскольку для поиска неотслеживаемых файлов в файловой системе требуется дополнительная работа, этот режим может занять некоторое время в большом рабочем дереве. Рассмотрите возможность включения неотслеживаемого кеша и разделенного индекса, если они поддерживаются (см. git update-index --untracked-cache и git update-index --split-index ). В противном случае вы можете использовать no для более быстрого возврата статуса git без отображения неотслеживаемых файлов.< /p>

Значение по умолчанию можно изменить с помощью переменной конфигурации status.showUntrackedFiles, описанной в git-config[1].

Игнорировать изменения в подмодулях при поиске изменений. может быть «нет», «неотслеживаемый», «грязный» или «все» по умолчанию. Использование «none» будет считать подмодуль измененным, если он либо содержит неотслеживаемые или измененные файлы, либо его HEAD отличается от фиксации, записанной в суперпроекте, и может использоваться для переопределения любых настроек параметра ignore в git- config[1] или gitmodules[5]. Когда используется «неотслеживаемый», подмодули не считаются грязными, если они содержат только неотслеживаемый контент (но они все еще сканируются на наличие измененного контента). Использование «грязного» игнорирует все изменения в рабочем дереве подмодулей, отображаются только изменения коммитов, хранящихся в суперпроекте (это было поведение до 1.7.0). Использование «всех» скрывает все изменения в подмодулях (и подавляет вывод сводных данных о подмодулях, если установлен параметр конфигурации status.submoduleSummary).

Показывать также игнорируемые файлы.

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

традиционный — показывает игнорируемые файлы и каталоги, если не указано --untracked-files=all, в этом случае отображаются отдельные файлы в игнорируемых каталогах.

no – не показывать проигнорированные файлы.

соответствие — показывает игнорируемые файлы и каталоги, соответствующие шаблону игнорирования.

Если указан режим matching, отображаются пути, которые явно соответствуют игнорируемому шаблону. Если каталог соответствует шаблону игнорирования, то отображается он, но не пути, содержащиеся в игнорируемом каталоге. Если каталог не соответствует шаблону игнорирования, но все содержимое игнорируется, то каталог не отображается, но отображается все содержимое.

Заканчивайте записи с помощью NUL вместо LF. Это подразумевает выходной формат --porcelain=v1, если не указан другой формат.

Отображать неотслеживаемые файлы в столбцах. Синтаксис параметра см. в переменной конфигурации column.status. --column и --no-column без опций эквивалентны всегда и никогда соответственно.

Отображать или не отображать подробные счетчики опережения/отставания для ветви относительно ее восходящей ветви. По умолчанию истинно.

Включить/выключить обнаружение переименования независимо от конфигурации пользователя. См. также git-diff[1] --no-renames .

Включите обнаружение переименования, при необходимости задав порог схожести. См. также git-diff[1] --find-renames .

ВЫВОД

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

Пути, упомянутые в выходных данных, в отличие от многих других команд Git, создаются относительно текущего каталога, если вы работаете в подкаталоге (это сделано специально, чтобы облегчить вырезание и вставку). См. параметр конфигурации status.relativePaths ниже.

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

В сокращенном формате статус каждого пути отображается в виде одной из этих форм

где ORIG_PATH – это источник переименованного/скопированного содержимого. ORIG_PATH отображается только при переименовании или копировании записи. XY — это двухбуквенный код состояния.

Поля (включая -> ) отделяются друг от друга одним пробелом. Если имя файла содержит пробелы или другие непечатаемые символы, это поле будет заключено в кавычки, как строковый литерал C: в двойных кавычках ASCII (34) и с внутренними специальными символами, экранированными обратной косой чертой.

Существует три разных типа состояний, отображаемых в этом формате, и каждый из них использует синтаксис XY по-разному:

Когда происходит слияние, и слияние было успешным, или вне ситуации слияния, X показывает состояние индекса, а Y показывает состояние рабочего дерева.

Если конфликт слияния возник и еще не разрешен, X и Y показывают состояние, введенное каждой головкой слияния, относительно общего предка. Эти пути называются неслитыми.

Когда путь не отслеживается, X и Y всегда одинаковы, так как они неизвестны индексу. ?? используется для неотслеживаемых путей. Игнорируемые файлы не отображаются в списке, если не используется параметр --ignored; если это так, игнорируемые файлы обозначаются !! .

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

В следующей таблице эти три класса показаны в отдельных разделах, и эти символы используются для полей X и Y для первых двух разделов, которые показывают отслеживаемые пути:

T = тип файла изменен (обычный файл, символическая ссылка или подмодуль)

C = скопировано (если для параметра конфигурации status.renames установлено значение «copies»)

U = обновлено, но не объединено

Подмодули имеют больше состояний и вместо этого сообщают M, что субмодуль имеет другой HEAD, чем указано в индексе m субмодуль изменил содержимое? в подмодуле есть неотслеживаемые файлы, поскольку измененное содержимое или неотслеживаемые файлы в подмодуле нельзя добавить с помощью git add в суперпроекте для подготовки фиксации.

m и ? применяются рекурсивно. Например, если вложенный подмодуль в подмодуль содержит неотслеживаемый файл, об этом также сообщается как ?.

Если используется -b, статусу в кратком формате предшествует строка

Фарфоровый формат, версия 1

Формат фарфора версии 1 аналогичен короткому формату, но гарантированно не будет обратно несовместимым образом между версиями Git или в зависимости от конфигурации пользователя. Это делает его идеальным для разбора скриптами. Приведенное выше описание короткого формата также относится к фарфоровому формату, за некоторыми исключениями:

Конфигурация пользователя color.status не соблюдается; цвет всегда будет отключен.

Конфигурация пользователя status.relativePaths не соблюдается; отображаемые пути всегда будут относиться к корню репозитория.

Существует также альтернативный формат -z, рекомендуемый для машинного синтаксического анализа. В этом формате поле статуса остается тем же, но кое-что меняется. Во-первых, -> опускается в записях переименования, а порядок полей меняется на противоположный (например, from -> to становится to from). Во-вторых, за каждым именем файла следует NUL (ASCII 0), заменяющий пробел в качестве разделителя полей и завершающий символ новой строки (но пробел по-прежнему отделяет поле состояния от первого имени файла). В-третьих, имена файлов, содержащие специальные символы, не форматируются особым образом; экранирование кавычек или обратной косой черты не выполняется.

О любых изменениях в подмодулях сообщается как об изменении M вместо m или single ? .

Фарфоровый формат, версия 2

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

Заголовки веток

Если задан параметр --branch, печатается ряд строк заголовка с информацией о текущей ветке.

Информация о тайнике

Если указан параметр --show-stash, печатается одна строка, показывающая количество записей в тайнике, если оно не равно нулю:

Измененные отслеживаемые записи

После заголовков печатается ряд строк для отслеживаемых записей. Для описания записи может использоваться один из трех различных форматов строк в зависимости от типа изменения. Отслеживаемые записи печатаются в неопределенном порядке; синтаксические анализаторы должны допускать сочетание трех типов строк в любом порядке.

Обычные измененные записи имеют следующий формат:

Переименованные или скопированные записи имеют следующий формат:

Необъединенные записи имеют следующий формат; первый символ - "u", чтобы отличить от обычных измененных записей.

Другие элементы

Вслед за отслеживаемыми записями (и по запросу) будет напечатан ряд строк для неотслеживаемых, а затем игнорируемых элементов, найденных в рабочем дереве.

Неотслеживаемые элементы имеют следующий формат:

Игнорируемые элементы имеют следующий формат:

Примечания к формату пути и -z

Если указан параметр -z, пути печатаются как есть и без кавычек, а строки заканчиваются байтом NUL (ASCII 0x00).

Без параметра -z пути с «необычными» символами заключаются в кавычки, как описано для переменной конфигурации core.quotePath (см. git-config[1]).

КОНФИГУРАЦИЯ

Команда учитывает color.status (или status.color — это одно и то же, последнее сохраняется для обратной совместимости) и color.status. переменные конфигурации, чтобы раскрасить вывод.

Если для переменной конфигурации status.relativePaths задано значение false, то все отображаемые пути относятся к корню репозитория, а не к текущему каталогу.

Если статус.submoduleSummary установлен на ненулевое число или true (идентично -1 или неограниченному числу), сводка подмодуля будет включена для длинного формата, и будет показана сводка коммитов для измененных подмодулей (см. параметр --summary-limit git-подмодуля[1]). Обратите внимание, что итоговый вывод команды состояния будет подавлен для всех подмодулей, если для diff.ignoreSubmodules задано значение all или только для тех подмодулей, где submodule. .игнорировать=все . Чтобы также просмотреть сводку для игнорируемых подмодулей, вы можете использовать параметр командной строки --ignore-submodules=dirty или команду git submodule summary, которая показывает аналогичный вывод, но не учитывает эти настройки.< /p>

ОБНОВЛЕНИЕ ФОНА

По умолчанию git status автоматически обновляет индекс, обновляя кешированную статистику из рабочего дерева и записывая результат. Запись обновленного индекса — это оптимизация, которая не является строго необходимой (статус вычисляет значения для себя, но их запись нужна только для того, чтобы последующие программы не повторяли наши вычисления). Когда статус выполняется в фоновом режиме, блокировка, удерживаемая во время записи, может конфликтовать с другими одновременными процессами, вызывая их сбой. Для статуса выполнения скриптов в фоновом режиме следует использовать статус git --no-Optional-locks (подробности см. в git[1]).

Установка и настройка

Получение и создание проектов

Базовый снимок

Ветвление и слияние

Обмен проектами и их обновление

Осмотр и сравнение

Исправление

Отладка

Электронная почта

Внешние системы

Администратор сервера

Руководства

Администрирование

Связные команды

Проверьте свою версию git, запустив

git-status — Показать статус рабочего дерева

ОБЗОР

ОПИСАНИЕ

ВАРИАНТЫ

Предоставьте результат в сокращенном формате.

Показывать ветку и информацию об отслеживании даже в сокращенном формате.

Предоставьте вывод в длинном формате. Это значение по умолчанию.

Показать неотслеживаемые файлы.

Параметр режима является необязательным (по умолчанию все) и используется для указания обработки неотслеживаемых файлов.

no — не показывать неотслеживаемые файлы.

обычный — показывает неотслеживаемые файлы и каталоги.

все – также показывает отдельные файлы в неотслеживаемых каталогах.

Если параметр -u не используется, отображаются неотслеживаемые файлы и каталоги (т. е. так же, как при указании normal ), чтобы вы не забыли добавить вновь созданные файлы. Поскольку для поиска неотслеживаемых файлов в файловой системе требуется дополнительная работа, этот режим может занять некоторое время в большом рабочем дереве. Вы можете использовать no для более быстрого возврата статуса git без отображения неотслеживаемых файлов.

Значение по умолчанию можно изменить с помощью переменной конфигурации status.showUntrackedFiles, описанной в git-config[1].

Игнорировать изменения в подмодулях при поиске изменений. может быть «нет», «неотслеживаемый», «грязный» или «все» по умолчанию. Использование «none» будет считать подмодуль измененным, если он либо содержит неотслеживаемые или измененные файлы, либо его HEAD отличается от фиксации, записанной в суперпроекте, и может использоваться для переопределения любых настроек параметра ignore в git- config[1] или gitmodules[5]. Когда используется «неотслеживаемый», подмодули не считаются грязными, если они содержат только неотслеживаемый контент (но они все еще сканируются на наличие измененного контента). Использование «грязного» игнорирует все изменения в рабочем дереве подмодулей, отображаются только изменения коммитов, хранящихся в суперпроекте (это было поведение до 1.7.0). Использование «все» скрывает все изменения в подмодулях (и подавляет вывод сводных данных о подмодулях, если установлен параметр конфигурации status.submodulesummary).

Показывать также игнорируемые файлы.

Заканчивайте записи с помощью NUL вместо LF. Это подразумевает выходной формат --porcelain, если не указан другой формат.

ВЫВОД

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

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

В сокращенном формате статус каждого пути отображается как

где PATH1 — это путь в HEAD , а часть « -> PATH2» отображается только тогда, когда PATH1 соответствует другому пути в индексе/рабочем дереве (т. е. файл переименован). XY — это двухбуквенный код состояния.

Для путей с конфликтами слияния X и Y показывают состояния модификации каждой стороны слияния. Для путей, не имеющих конфликтов слияния, X показывает статус индекса, а Y показывает статус рабочего дерева. Для неотслеживаемых путей XY равны ?? . Другие коды состояния можно интерпретировать следующим образом:

В последнем руководстве по фиксации изменений внутри Git мы узнали, что сначала нам нужно перенести файл в промежуточную область, а затем зафиксировать оттуда. Работая одновременно с разными файлами в одном и том же репозитории, вы можете потерять след сделанных вами изменений. Вы можете забыть, что вы что-то изменили, или, может быть, вы добавили новый файл, который сейчас бесполезен. Вам нужно что-то, что поможет вам отслеживать его. В Git эта работа выполняется с помощью команды git status. В этом руководстве мы сосредоточимся на команде git status.

Команда статуса Git

Команда Git status используется в Git, чтобы узнать статус рабочего дерева. Он показывает состояние вашего рабочего каталога и помогает вам увидеть все файлы, которые не отслеживаются Git, размещены или не помещены в архив. Короче говоря, Git покажет вам любую разницу в текущем дереве и указателе HEAD (Ссылка Терминология Git). Наряду с этим статусом Git вы также увидите измененный или новый файл в репозитории. Мы рассмотрим каждый из них на примерах. Мы рассмотрим следующие случаи использования Git Status

Статус Git, когда рабочее дерево — Чисто

Прежде чем вносить какие-либо новые изменения, давайте посмотрим на состояние репозитория Git, в котором мы работаем (Первый проект). Обратитесь к репозиторию Git

1.Откройте Git Bash

Перейдите в каталог репозитория (Первый проект).

Введите следующую команду git status и нажмите enter, чтобы выполнить команду.

Как видно, коммитить нечего, а рабочее дерево чистое, т. е. нет неотслеживаемых файлов.

Статус Git при создании нового файла

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

1.Создайте файл ABC.txt с помощью команды:

Примечание. Команда touch — самый простой способ создать новые пустые файлы.

Нажмите ввод, чтобы создать файл.

После создания файла снова выполните команду git status.

Совершенно ясно, что сообщение фиксировать нечего, но присутствуют неотслеживаемые файлы. Неотслеживаемые файлы, как описано в руководстве по Git commit, — это файлы, которые еще не добавлены в промежуточную область. В Git есть два типа неотслеживаемых файлов. Один из них — это обычный файл проекта, который мы видели выше, а другой — двоичные файлы, находящиеся внутри репозитория, такие как .obj или .exe.

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

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

новый файл: ABC.txt. Это говорит о наличии нового файла (с его именем), который также был добавлен в промежуточную среду.

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

После успешной фиксации файла вы можете еще раз проверить статус git, и он покажет вам, что коммитить нечего.

Теперь мы посмотрим, что происходит при изменении существующего файла.

Статус Git при изменении существующего файла

В этом разделе мы увидим ответ git status при выполнении файла, который был недавно изменен.

1.Введите одно предложение в файл ABC.txt

Примечание. Команда echo используется для добавления текста в текстовый файл.

Нажмите ввод, чтобы записать это предложение в файл ABC.txt. Сделав это, еще раз выполните команду git status, чтобы увидеть, что теперь она говорит.

modified: ABC.txt : это говорит о том, что файл ABC.txt был изменен. Он выделен красным, потому что мы еще не добавили его в тестовую область, и по этой причине в нижней строке указано, что не добавлено никаких изменений для фиксации.

Добавьте файл в промежуточную область с помощью команды git add, а затем снова введите git status, чтобы увидеть статус.

изменено: ABC.txt: это сообщение изменено с красного на зеленый. Также исчезло сообщение о том, что ничего не нужно коммитить. Это означает, что наш файл находится в промежуточной области, он отслеживается и есть изменения, которые нужно зафиксировать. Зафиксируйте файл, чтобы зафиксировать изменения, которые мы только что сделали.

Статус Git, когда файл удален

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

Чтобы удалить файл (ABC.txt), введите следующую команду и нажмите enter, чтобы удалить файл.

Примечание. RM означает удалить.

После удаления файла снова проверьте команду git status.

удален: ABC.txt: в сообщении говорится, что файл с именем ABC.txt удален.

Вы можете зафиксировать изменения, как мы это делали в предыдущих разделах. Очень важно попрактиковаться в команде git status перед выполнением любого коммита. Поскольку вы, возможно, не хотите, чтобы происходили какие-либо нежелательные коммиты. Кроме того, он предоставит вам информацию о последних изменениях, которые произошли. Говоря о фиксации изменений, мы перейдем к нашему следующему руководству, где мы узнаем о фиксации изменений с помощью хороших сообщений фиксации.

Читайте также: