За исключением восстановления с помощью (например) MacOS Time Machine или резервных копий, вам, вероятно, не повезло.
"Unstaged changes" вводит в заблуждение в Git.Там нет таких вещей.Всего файлов рабочего дерева .Когда Git говорит, что файл рабочего дерева отличается, это верное утверждение: копия рабочего дерева отличается от некоторой другой копии.Когда Git показывает разницу, это построено на , сравнивающее копию рабочего дерева с другой копией.
Если разница исчезнет, один (или оба!)из двух вещей, которые должны были произойти:
Другая копия теперь совпадает: поэтому копия рабочего дерева все та же, но другая копия совпадает.Вот что происходит, например, когда вы добавляете и фиксируете: git add копирует копию рабочего дерева каждого файла для замены устаревшей индексной копии, а затем коммит делает новый коммит из индексной копии.
Или, копия рабочего дерева теперь совпадает: старая копия рабочего дерева была выброшена и заменена копией с того, с чем вы сравнивали (индекс или HEADкоммит, скорее всего).
Стоит помнить, что при использовании Git каждый коммит имеет полную и полную копию из каждого файла(ну, каждый файл, который находится в коммите, но это отчасти избыточно), замороженный в этой форме навсегда. 1 Но эти копии находятся в специальной, только для Git, сжатой форме.Они бесполезны ни для чего , кроме Git.
Следовательно, Git предоставляет способ извлекать файлов из коммитов, поворачивая ихвернуться в свою полезную форму.Это помещает копию файла в рабочее дерево, где вы можете просматривать и работать с ним.Эти копии не управляются и не поддерживаются Git , они просто находятся там в рабочем дереве после того, как Git извлечет их.Git не может нести за них ответственность, кроме как во время процесса извлечения, когда он их создает (или заменяет их содержимое тем, что извлечено).
Между текущим (замороженным) HEAD коммитом и (полностью жидким)рабочее дерево, не управляемое Git, Git также хранит своего рода «почти замороженную» или «слякотную» копию каждого файла.Эта копия изначально соответствует фиксации HEAD, и она всегда в специальном формате Git.
Эти копии каждого файла живут в том, что Git вызывает, по-разному, index , область подготовки или кеш , в зависимости от того, кто / какая часть Git выполняет вызов.
Когда вы используете git add, вы говорите Git: возьмите все, что есть в копии рабочего дерева, и скопируйте это обратно в индекс, заменив старую копию индекса .Это Git-содержимое файла, получая их в основном замороженными, чтобы они были готовы перейти к next commit.Если файл, который вы git add -ing ранее не был в индексе, теперь он в индексе в специальной форме только для Git, готов к фиксации.
СледовательноЛучшее короткое описание индекса, которое я знаю, это то, что это коммит, который вы предлагаете сделать следующим .У него есть собственная копия каждого файла, готовая к фиксации.Это то, что делает git commit настолько быстрым, по сравнению с большинством других систем управления версиями, ориентированными на коммиты: другие должны сканировать, часто мучительно медленно, по всему вашему рабочему дереву, повторно сжимая каждый файл впосмотрите, отличается ли он, или подготовьте его к следующему коммиту.Сохраняя те из текущих коммитов в этот индекс, Git готовит их для следующего коммита.
Таким образом, существует три копии каждого файла: копия HEAD, индексная копия и копия рабочего дерева.Копия HEAD (текущая фиксация) заморожена и безопасна, как и любая подтвержденная копия.Индекс и копии рабочего дерева могут быть изменены.Если вы хотите быть уверенным, что файл не потерян, вы копируете его в индекс и фиксируете его.Иногда вы можете удалить коммит позже, используя git rebase -i, чтобы раздавить вещи.
1 Точнее, копия файла в коммите длится до тех пор, пока коммитсам длитсяВ основном это навсегда;но если вы делаете какие-то коммиты, никогда не отправляете и не отправляете их кому-либо, а затем используете git rebase -i, чтобы объединить их вместе, вы получите один финальный коммит, а остальные промежуточные в конечном итоге истекают (и никогда не отправляются / не отправляются).