Зачем Git нужно создавать Index / Stage?

Question

На следующем рисунке показана схема Git, мне очень странно, почему Git нужно спроектировать Index /Stage.

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

Почему Git требуется для разработки Index / Stage?

Изображение

Answer 1

Размещаемые файлы служат дисплеем, на котором коммиттер может видеть изменения, которые он собирается добавить в этот конкретный коммит.Это также помогает при наборе git commit -a, что является плохой практикой, о которой упоминал @ Romain.

Ниже приведен еще один пример использования. У вас есть изменения в a.txt и b.txt, но вам нужно выполнить дваотдельные коммиты для этих файлов по тем или иным причинам (возможно, переместите a.txt в другую ветку и b.txt в другую ветку!).Представьте себе работу, которую предстоит выполнить!

Индексированный файл просто облегчает жизнь разработчикам, это не слепое дизайнерское решение.

Answer 2

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

Тем не менее, Git значительно быстрее , чем Mercurial.Большая часть этой скорости является результатом того, что Git сохраняет свой отдельный индекс (хотя во многом это также связано с реализацией Mercurial на Python, а не на C).Таким образом, присутствие индекса делает Git немного «быстрым», если хотите.

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

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

После того, как вы увлеклись идеей отдельной промежуточной области, это дает третий мотив: теперь вы можете создавать дополнительные промежуточные области всякий раз, когдаВы хотите, если это полезно для какой-то конкретной цели.Так, например, реализовано git stash.(Это также относится к git worktree add, хотя дополнительные рабочие деревья добавляются в виде пары : , вы получаете новое рабочее дерево с новым индексом. Если что-то, это доказывает, что новое рабочее дерево должно be новый индекс, т. Е. Модель Mercurial лучше!)

Answer 3

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

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

Я бы посоветовал посмотреть это , среди других статей.