git commit переместит / скопирует файлы из промежуточной области в локальную ветку

Question

У меня много недоразумений по поводу области подготовки . во-первых, Git Gud: рабочее дерево, промежуточная область и локальный репо скажите , что промежуточная область будет пустой после git commit , поэтому git commit может переместить файлы в локальную папку ветвь, а не копия.

Но казалось, что это не может объяснить эту практику: git reset --soft HEAD ~ изменяет промежуточный снимок? . git reset --soft HEAD ^ после git commit , а затем git status , казалось, что существует разница между областью подготовки и HEAD ^ и разница в файлах, которые были зафиксированы после HEAD ^. Таким образом, казалось, что область подготовки не пуста после git commit , или, скорее, как объяснить разницу между текущим HEAD и областью подготовки, если область подготовки пуста?

---

И еще вопрос в том, что команда

  git diff --cached

, который использовался для сравнения разницы между областью подготовки и HEAD. И Что означает «stage» в git? говорит мне, что в области подготовки хранятся только изменения файла. Например, мы git клонируем проект, который имеет три файла: a.txt b.txt c.txt, и мы изменили c.txt и git добавили it. Затем мы выполняем команду git diff --cached . Теперь в локальном филиале три файла, а в области подготовки - только один. почему он показывает только изменение c.txt, но не включает информацию о том, что область размещения не имеет a.txt b.txt по сравнению с локальной веткой.

---

Одним словом, у меня два вопроса:
1. что произошло, когда git commit , переместил или скопировал файл из промежуточной области в локальную ветку?
2. что произошло, когда git diff --cached ? просто сравнить файлы, которые содержит промежуточная область?

справка:

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

Answer 1

Многие статьи свободно говорят о том, что это за стадия (или, если уж на то пошло, коммит) / что она содержит. Возможно, некоторые из этих авторов не знают лучше, или, возможно, они просто думают, что их объяснение более полезно, чем более точное. Независимо от причины, будьте осторожны:

Если кто-то говорит вам, что индекс содержит изменения, он вводит вас в заблуждение.

Индекс содержит снимок проекта. (Обычно. Во время конфликтного слияния это немного сложнее.) Если кто-то говорит, что оно «содержит поэтапные изменения», вы должны понимать, что на самом деле оно содержит снимок , к которому были применены поэтапные изменения (относительно объект COMMIT, обозначенный HEAD).

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

Answer 2

Относительно git diff --cached

Здесь обсуждается использование diff для сравнения рабочей области, индекса и удаленного репо, здесь: https://stackoverflow.com/a/41249720/4522186

Answer 3

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

Когда вы делаете git add, изменения добавляются в промежуточную сцену до тех пор, пока вы на самом деле не выполните git commit. После того, как вы подготовили файл для фиксации, вы можете внести дополнительные изменения, и они появятся в Changes not staged for commit: части git status. Когда вы действительно запускаете git commit, изменения, которые вы сделали, используются для создания нового коммита, а шаком этого коммита становится новый HEAD.

Ваш второй вопрос из справочной документации git diff:

git diff [--options] --cached [] [-] [...] Эта форма предназначена для просмотра изменений, которые вы поставили для следующего коммита относительно именованного. Как правило, вы хотели бы сравнение с последним commit, поэтому, если вы не дадите, по умолчанию используется HEAD. Если HEAD не существует (например, нерожденные ветви) и не задан, он показывает все постановочные изменения. --staged является синонимом --cached.

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

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