Что означает пространство перед несколькими именами файлов при выполнении команды git status -s?

Question

Когда я делаю git status -s Я получаю следующий вывод:

 M package.json
D  public/ewew.js
 M script.sh
M  src/TaskList.js
 D test.js
AD test2.js

Что означает пробел в начале нескольких строк? (1-я, 3-я и 5-я строка)

Answer 1

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

X          Y     Meaning
-------------------------------------------------
          [MD]   not updated
M        [ MD]   updated in index
A        [ MD]   added to index
D         [ M]   deleted from index
R        [ MD]   renamed in index
C        [ MD]   copied in index
[MARC]           index and work tree matches
[ MARC]     M    work tree changed since index
[ MARC]     D    deleted in work tree
-------------------------------------------------
D           D    unmerged, both deleted
A           U    unmerged, added by us
U           D    unmerged, deleted by them
U           A    unmerged, added by them
D           U    unmerged, deleted by us
A           A    unmerged, both added
U           U    unmerged, both modified
-------------------------------------------------
?           ?    untracked
!           !    ignored
-------------------------------------------------

В вашем случае X - это пробел, так что это применимо:

X          Y     Meaning
-------------------------------------------------
          [MD]   not updated

Answer 2

Наряду с другими вещами, которые он делает, git status работает два (не один, а два) git diff команды. Поэтому, показывая вам --short или же -s Для вывода статуса необходимо суммировать результаты обоих различий, поэтому для каждой возможной буквы статуса есть две позиции.

Помните, что в Git всегда может быть до трех копий каждого файла.¹ Есть один случай, например, package.json в HEAD совершить, вторая версия package.json в индексе (также называемом промежуточной областью или кэшем) и третьей версией package.json в рабочем дереве.

Версия package.json в текущем коммите никогда нельзя изменить, потому что ни один файл в коммите никогда не может быть изменен. (Вы можете изменить текущий коммит, который изменит HEAD версия файла путем изменения HEAD сам: например, вместо головы ac0ffee, может быть, сейчас ГОЛОВА feeddad, Но файлы, хранящиеся в этих коммитах, всегда сохраняются в этих коммитах, навсегда.)

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

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

Схематически:

  HEAD          index         work-tree
--------       --------       --------
package.json   package.json   package.json
public/ewew.js
script.sh      script.sh      script.sh
           :              :
               test2.js

git status Команда сначала сравнивает HEAD version к версии index, затем сравнивает версию index с версией рабочего дерева.

Статус для этого test2.jsнапример, AD: это означает, что он отсутствует в HEAD, Таким образом, для HEAD-vs-index, он был добавлен, а затем снова отсутствует в рабочем дереве, поэтому для index-vs-work-tree он был удален.

Статус для script.sh это Space-M, так что версии в HEAD и индекс совпадает (пробел), но версии в индексе и рабочем дереве различаются (M). Статус для src/TaskList.js М-пространство, так что версия в HEAD отличается от версии в индексе, а версия в индексе совпадает с версией в рабочем дереве.

Если вы сделаете коммит прямо сейчас, то в новый коммит войдет то, что сейчас находится в индексе. Чтобы увидеть все, что сейчас находится в индексе, используйте git ls-files --stage, Обычно, однако, разница между HEAD и индекс - то есть файлы, "подготовленные для фиксации" или первый столбец краткого статуса - более интересен. Аналогично, разница между индексом и рабочим деревом, т. Е. Файлами, которые можно подготовить для фиксации, интересна, поэтому существует второй столбец.

---

¹ Технически, Git может в любое время сохранить до пяти копий любого файла, хотя иногда всего лишь один. Это связано с тем, что индексная / промежуточная область также используется при выполнении разрешения слияния конфликтующего файла, т. Е. Когда вы находитесь в середине конфликтующего слияния. В этом случае он содержит три копии одного файла: версия слиянием, --ours версия, а --theirs версия. Но для этого конкретного ответа, просто подумайте о нем как о "трех экземплярах": не беспокойтесь о других случаях, пока вы не выполните слияние.