Что

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

07.11.202303.04.2023 admin 0 Comments

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

Check your version of git by running

SYNOPSIS

DESCRIPTION

OPTIONS

Give the output in the short-format.

Show the branch and tracking info even in short-format.

Show the number of entries currently stashed away.

Give the output in an easy-to-parse format for scripts. This is similar to the short output, but will remain stable across Git versions and regardless of user configuration. See below for details.

The version parameter is used to specify the format version. This is optional and defaults to the original version v1 format.

Give the output in the long-format. This is the default.

Show untracked files.

The possible options are:

The default can be changed using the status.showUntrackedFiles configuration variable documented in git-config[1].

Ignore changes to submodules when looking for changes. can be either «none», «untracked», «dirty» or «all», which is the default. Using «none» will consider the submodule modified when it either contains untracked or modified files or its HEAD differs from the commit recorded in the superproject and can be used to override any settings of the ignore option in git-config[1] or gitmodules[5]. When «untracked» is used submodules are not considered dirty when they only contain untracked content (but they are still scanned for modified content). Using «dirty» ignores all changes to the work tree of submodules, only changes to the commits stored in the superproject are shown (this was the behavior before 1.7.0). Using «all» hides all changes to submodules (and suppresses the output of submodule summaries when the config option status.submoduleSummary is set).

Show ignored files as well.

The mode parameter is used to specify the handling of ignored files. It is optional: it defaults to traditional.

The possible options are:

When matching mode is specified, paths that explicitly match an ignored pattern are shown. If a directory matches an ignore pattern, then it is shown, but not paths contained in the ignored directory. If a directory does not match an ignore pattern, but all contents are ignored, then the directory is not shown, but all contents are shown.

Display or do not display detailed ahead/behind counts for the branch relative to its upstream branch. Defaults to true.

OUTPUT

The output from this command is designed to be used as a commit template comment. The default, long format, is designed to be human readable, verbose and descriptive. Its contents and format are subject to change at any time.

The paths mentioned in the output, unlike many other Git commands, are made relative to the current directory if you are working in a subdirectory (this is on purpose, to help cutting and pasting). See the status.relativePaths config option below.

Short Format

In the short-format, the status of each path is shown as one of these forms

where ORIG_PATH is where the renamed/copied contents came from. ORIG_PATH is only shown when the entry is renamed or copied. The XY is a two-letter status code.

There are three different types of states that are shown using this format, and each one uses the XY syntax differently:

When a merge is occurring and the merge was successful, or outside of a merge situation, X shows the status of the index and Y shows the status of the working tree.

When a merge conflict has occurred and has not yet been resolved, X and Y show the state introduced by each head of the merge, relative to the common ancestor. These paths are said to be unmerged.

In the following table, these three classes are shown in separate sections, and these characters are used for X and Y fields for the first two sections that show tracked paths:

T = file type changed (regular file, symbolic link or submodule)

C = copied (if config option status.renames is set to «copies»)

U = updated but unmerged

m and ? are applied recursively. For example if a nested submodule in a submodule contains an untracked file, this is reported as ? as well.

Porcelain Format Version 1

Version 1 porcelain format is similar to the short format, but is guaranteed not to change in a backwards-incompatible way between Git versions or based on user configuration. This makes it ideal for parsing by scripts. The description of the short format above also describes the porcelain format, with a few exceptions:

The user’s color.status configuration is not respected; color will always be off.

The user’s status.relativePaths configuration is not respected; paths shown will always be relative to the repository root.

Porcelain Format Version 2

Version 2 format adds more detailed information about the state of the worktree and changed items. Version 2 also defines an extensible set of easy to parse optional headers.

Header lines start with «#» and are added in response to specific command line arguments. Parsers should ignore headers they don’t recognize.

Branch Headers

Changed Tracked Entries

Following the headers, a series of lines are printed for tracked entries. One of three different line formats may be used to describe an entry depending on the type of change. Tracked entries are printed in an undefined order; parsers should allow for a mixture of the 3 line types in any order.

Ordinary changed entries have the following format:

Renamed or copied entries have the following format:

Unmerged entries have the following format; the first character is a «u» to distinguish from ordinary changed entries.

Other Items

Following the tracked entries (and if requested), a series of lines will be printed for untracked and then ignored items found in the worktree.

Untracked items have the following format:

Ignored items have the following format:

CONFIGURATION

The command honors color.status (or status.color — they mean the same thing and the latter is kept for backward compatibility) and color.status. configuration variables to colorize its output.

If the config variable status.relativePaths is set to false, then all paths shown are relative to the repository root, not to the current directory.

BACKGROUND REFRESH

Источник

Запись изменений в репозиторий

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

Запомните, каждый файл в вашем рабочем каталоге может находиться в одном из двух состояний: под версионным контролем (отслеживаемые) и нет (неотслеживаемые). Отслеживаемые файлы — это те файлы, которые были в последнем снимке состояния проекта; они могут быть неизменёнными, изменёнными или подготовленными к коммиту. Если кратко, то отслеживаемые файлы — это те файлы, о которых знает Git.

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

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

Определение состояния файлов

Отслеживание новых файлов

Индексация изменённых файлов

Теперь оба файла проиндексированы и войдут в следующий коммит. В этот момент вы, предположим, вспомнили одно небольшое изменение, которое вы хотите сделать в CONTRIBUTING.md до коммита. Вы открываете файл, вносите и сохраняете необходимые изменения и вроде бы готовы к коммиту. Но давайте-ка ещё раз выполним git status :

Сокращенный вывод статуса

Игнорирование файлов

Первая строка предписывает Git игнорировать любые файлы заканчивающиеся на «.o» или «.a» — объектные и архивные файлы, которые могут появиться во время сборки кода. Вторая строка предписывает игнорировать все файлы заканчивающиеся на тильду (

Стандартные шаблоны являются глобальными и применяются рекурсивно для всего дерева каталогов.

Чтобы избежать рекурсии используйте символ слеш (/) в начале шаблона.

Чтобы исключить каталог добавьте слеш (/) в конец шаблона.

Можно инвертировать шаблон, использовав восклицательный знак (!) в качестве первого символа.

Просмотр индексированных и неиндексированных изменений

Чтобы увидеть, что же вы изменили, но пока не проиндексировали, наберите git diff без аргументов:

Эта команда сравнивает содержимое вашего рабочего каталога с содержимым индекса. Результат показывает ещё не проиндексированные изменения.

Важно отметить, что git diff сама по себе не показывает все изменения сделанные с последнего коммита — только те, что ещё не проиндексированы. Такое поведение может сбивать с толку, так как если вы проиндексируете все свои изменения, то git diff ничего не вернёт.

Другой пример: вы проиндексировали файл CONTRIBUTING.md и затем изменили его, вы можете использовать git diff для просмотра как проиндексированных изменений в этом файле, так и тех, что пока не проиндексированы. Если наше окружение выглядит вот так:

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

Коммит изменений

Эта команда откроет выбранный вами текстовый редактор.

В редакторе будет отображён следующий текст (это пример окна Vim):

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

Итак, вы создали свой первый коммит! Вы можете видеть, что коммит вывел вам немного информации о себе: на какую ветку вы выполнили коммит ( master ), какая контрольная сумма SHA-1 у этого коммита ( 463dc4f ), сколько файлов было изменено, а также статистику по добавленным/удалённым строкам в этом коммите.

Запомните, что коммит сохраняет снимок состояния вашего индекса. Всё, что вы не проиндексировали, так и висит в рабочем каталоге как изменённое; вы можете сделать ещё один коммит, чтобы добавить эти изменения в репозиторий. Каждый раз, когда вы делаете коммит, вы сохраняете снимок состояния вашего проекта, который позже вы можете восстановить или с которым можно сравнить текущее состояние.

Игнорирование индексации

Удаление файлов

Если вы просто удалите файл из своего рабочего каталога, он будет показан в секции «Changes not staged for commit» (измененные, но не проиндексированные) вывода команды git status :

В команду git rm можно передавать файлы, каталоги или шаблоны. Это означает, что вы можете сделать что-то вроде:

Эта команда удаляет все файлы, имена которых заканчиваются на

Перемещение файлов

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

Таким образом, наличие в Git команды mv выглядит несколько странным. Если вам хочется переименовать файл в Git, вы можете сделать что-то вроде:

и это отлично сработает. На самом деле, если вы выполните что-то вроде этого и посмотрите на статус, вы увидите, что Git считает, что произошло переименование файла:

Однако, это эквивалентно выполнению следующих команд:

Источник

Введение в Git

Навигация (только номера заданий)

0 из 38 заданий окончено

Информация

Тест на проверку знаний по Git

Вы уже проходили тест ранее. Вы не можете запустить его снова.

Вы должны войти или зарегистрироваться для того, чтобы начать тест.

Вы должны закончить следующие тесты, чтобы начать этот:

Результаты

Правильных ответов: 0 из 38

Вы набрали 0 из 0 баллов ( 0 )

Рубрики

GIT — это единственная система контроля версий?

Подробнее можно посмотреть здесь: https://git-scm.com/book/

Что такое репозиторий Git?

Что делает команда git status?

Что делает команда git add?

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

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

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

Как сделать коммит?

В какой ситуации надо делать git status?

Что такое ветка в репозитории Git?

Чем отличаются команды «git push» и «git pull»?

Что делает команда git log?

Что делает команда git show?

Подробнее можно посмотреть здесь: http://dev-lab.info/

Как узнать кто автор строки в файле, используя систему Git?

Подробнее можно посмотреть здесь: https://git-scm.com/book/

Как узнать, какие изменения мы сделали локально, относительно последнего состояния нашего репозитория?

Как отменить действие команды «git add» для файла?

Как решить конфликт в Git?

Как привести измененный файл в начальное состояние (до изменения)?

Что делает команда git stash?

Как отменить слияние веток, если произошел конфликт?

Как применить патч в Git?

Сколько всего веток может быть в репозитории?

Что произойдет после выполнения команды «git branch» без какого либо параметра?

Как сделать коммит на ветке my_branch?

Как удалить локальную ветку my_branch?

Как исправить ошибку «fatal: The current branch my_branch has no upstream branch», возникающую при вводе git push?

Источник

Добавление, удаление и отслеживание изменений в Git (git add, git status, git remove)

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

Эта статья полностью посвящена работе с локальным репозиторием и отслеживаемыми / не отслеживаемыми изменениями. Мы будем охватывать следующие команды git:

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

После этого репозиторий git будет выглядеть следующим образом:

Git Status

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

1) Теперь откройте командную строку и перейдите в репозиторий git

2) Просто введите git status в командной строке.

branch master: говорит о том, что рабочее дерево является главной ветвью.

no commits yet: дает информацию о коммитах, на данный момент их еще нет.

Untracked files: говорит о том, что Git видит файлы, но еще не начал отслеживать изменения и отметил их красным цветом.

Status messages: дает соответствующие инструкции для промежуточных / нестагнирующих файлов.

Git add

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

1) Давайте просто начнем с добавления одного файла к заявке. Чтобы использовать команду git add, просто введите git add filename. Слово filename здесь относится к имени файла, который вы редактировали, например CustomerData_IND.txt. Кроме того, используйте команду git status, чтобы увидеть, что git теперь может рассказать нам о состоянии репозитория.

Changes to be comitted: здесь отображается информация о отслеживаемых файлах, хранящихся на промежуточном этапе. Это тот самый, который мы добавили с помощью команды git add.

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

Команда Git Remove

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

Чтобы практиковать эту команду, давайте попробуем удалить тот же CustomerData_IND.txt, который был добавлен ранее.

Untracked files: CustomerData_IND.txt файл вернулся к списку игнорируемых изменения.

Добавление различных измененных файлов в промежуточную среду

Выше мы просто добавили один файл в staging. Что делать, если там будет несколько файлов для добавления. Это может быть легко достигнуто с помощью git add .

Чтобы добавить несколько файлов, введите

git add CustomerData_IND.txt CustomerData_UK.txt

.» width=»837″ height=»370″ srcset=»https://www.lenakso.top/wp-content/uploads/2020/04/Git_Repository_13.png 837w, https://www.lenakso.top/wp-content/uploads/2020/04/Git_Repository_13-300×133.png 300w, https://www.lenakso.top/wp-content/uploads/2020/04/Git_Repository_13-768×339.png 768w, https://www.lenakso.top/wp-content/uploads/2020/04/Git_Repository_13-660×292.png 660w» sizes=»(max-width: 837px) 100vw, 837px» />

Удаление различных файлов из промежуточного состояния

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

Чтобы удалить несколько файлов, введите

.» width=»837″ height=»370″ srcset=»https://www.lenakso.top/wp-content/uploads/2020/04/Git_Repository_14.png 837w, https://www.lenakso.top/wp-content/uploads/2020/04/Git_Repository_14-300×133.png 300w, https://www.lenakso.top/wp-content/uploads/2020/04/Git_Repository_14-768×339.png 768w, https://www.lenakso.top/wp-content/uploads/2020/04/Git_Repository_14-660×292.png 660w» sizes=»(max-width: 837px) 100vw, 837px» />

Примечание: это двойной дефис, « — — » но без пробела перед ключевым словом cached.

Вывод: упомянутые два файла в команде теперь удаляются из промежуточного состояния и возвращаются в неотслеживаемый список.

Добавим все измененные файлы в промежуточную версию

Выше мы добавили несколько файлов в staging, но что делать, если там будет много файлов для добавления? Это может быть легко достигнуто с помощью git add *.

Чтобы добавить все измененные файлы, введите git add *

Все измененные файлы теперь перемещаются в промежуточный режим.

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

В последнем уроке мы познакомились с командой Git fetch и Read more

В одной из последних статей мы узнали о команде Git Read more

Мы уже знаем, как вносить изменения в локальное хранилище и Read more

Команда git push при выполнении перемещает изменения, внесенные пользователем на Read more

«Клонирование» означает создание идентичных особей естественным или искусственным путем. Клонирование Read more

Сегодня мы узнаем, как скопировать чужой репозиторий в наш аккаунт Read more

Источник

Введение в Git

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

Git имеет три основных состояния, в которых могут находиться ваши файлы: зафиксированном (committed), изменённом (modified) и подготовленном (staged). «Зафиксированный» значит, что файл уже сохранён в вашей локальной базе. К изменённым относятся файлы, которые поменялись, но ещё не были зафиксированы. Подготовленные файлы — это изменённые файлы, отмеченные для включения в следующий коммит.

Мы подошли к трём основным секциям проекта Git: Git-директория (Git directory), рабочая директория (working directory) и область подготовленных файлов (staging area).

Git-директория — это то место, где Git хранит метаданные и базу объектов вашего проекта. Это самая важная часть Git, и это та часть, которая копируется при клонировании репозитория с другого компьютера.

Рабочая директория является снимком версии проекта. Файлы распаковываются из сжатой базы данных в Git-директории и располагаются на диске, для того чтобы их можно было изменять и использовать.

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

Базовый подход в работе с Git выглядит так:

Если определённая версия файла есть в Git-директории, эта версия закоммичена. Если файл изменён и добавлен в индекс, значит, он будет добавлен в следующий коммит. И если файл был изменён с момента последнего распаковывания из репозитория, но не был добавлен в индекс, он считается изменённым.

Первоначальная настройка Git

Теперь, когда Git установлен в вашей системе, самое время настроить среду для работы с Git’ом под себя. Это нужно сделать только один раз — при обновлении версии Git’а настройки сохранятся. Но, при необходимости, вы можете поменять их в любой момент, выполнив те же команды снова.

Имя пользователя

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

Проверка настроек

Некоторые ключи (названия) настроек могут появиться несколько раз, потому что Git читает один и тот же ключ из разных файлов (например, из /etc/gitconfig и

/.gitconfig ). В этом случае Git использует последнее значение для каждого ключа.

Также вы можете проверить значение конкретного ключа, выполнив git config :

Как получить помощь?

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

Например, так можно открыть руководство по команде config

Создание Git-репозитория

Для создания Git-репозитория вы можете использовать два основных подхода. Во-первых, cоздание репозитория в существующей директории. Во-вторых, клонирование существующего репозитория с другого сервера.

Создание репозитория в существующей директории

Если вы собираетесь начать использовать Git для существующего проекта, то вам необходимо перейти в директорию проекта и в командной строке ввести

Клонирование существующего репозитория

Запись изменений в репозиторий

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

Отслеживаемые файлы — это те файлы, которые были в последнем слепке состояния проекта; они могут быть неизменёнными, изменёнными или подготовленными к коммиту (staged).

Неотслеживаемые файлы — это всё остальное, любые файлы в вашем рабочем каталоге, которые не входили в ваш последний слепок состояния и не подготовлены к коммиту.

Как только вы отредактируете файлы, Git будет рассматривать их как изменённые, т.к. вы изменили их с момента последнего коммита. Вы индексируете (stage) эти изменения и затем фиксируете все индексированные изменения (commit).