В качестве небольшого дополнительного объяснения обратите внимание, что git stashвыполняется либо две, либо три фиксации. По умолчанию два; вы получите три, если используете любое написание --allили --include-untracked.
Эти два, или три, совершающие специальные в одном важном пути: они находятся на нет отрасли. Git находит их по специальному имени stash. 1 Однако самое важное - это то, что Git позволяет - и заставляет - делать с этими двумя или тремя коммитами. Чтобы понять это, нам нужно посмотреть, что находится в этих коммитах.
Что внутри тайника
Каждая фиксация может содержать одну или несколько родительских коммитов. Они образуют график, где более поздние фиксации указывают на более ранние. Тайник обычно содержит две фиксации, которые я люблю вызывать iдля содержимого индексной / промежуточной области и wдля содержимого рабочего дерева. Помните также, что каждый коммит содержит снимок. При обычной фиксации этот снимок создается из содержимого области индекса / промежуточной области. Таким образом, iфиксация на самом деле является совершенно нормальной фиксацией! Его просто нет ни в одной ветке:
...--o--o--o <-- branch (HEAD)
|
i
Если вы создаете обычный тайник, git stashкод wтеперь копирует все ваши отслеживаемые файлы рабочего дерева (во временный вспомогательный индекс). Git устанавливает, что первый родительский элемент этой wфиксации указывает на HEADфиксацию, а второй родительский элемент указывает на фиксацию i. Наконец, он stashуказывает на этот wкоммит:
...--o--o--o <-- branch (HEAD)
|\
i-w <-- stash
Если вы добавите --include-untrackedили --all, Git сделает дополнительную фиксацию, uмежду созданием iи w. Содержимое моментального снимка u- это файлы, которые не отслеживаются, но не игнорируются ( --include-untracked), или файлы, которые не отслеживаются, даже если они игнорируются ( --all). Это дополнительное uобязательство не имеют нет родителей, а затем , когда git stashмарка w, она устанавливает w«s третьего родителя это uсовершить, так что вы получите:
...--o--o--o <-- branch (HEAD)
|\
i-w <-- stash
/
u
Git также, на этом этапе, удаляет все файлы рабочего дерева, которые были завершены в uфиксации (используя git cleanдля этого).
Восстановление тайника
Когда вы собираетесь восстановить тайник, у вас есть возможность использовать --indexили не использовать его. Это говорит git stash apply(или какой - либо из команд , которые внутренне использовать apply, например pop) , что он должен использоватьi совершить , чтобы попытаться изменить свой текущий индекс. Эта модификация выполняется с помощью:
git diff <hash-of-i> <hash-of-i's-parent> | git apply --index
(более или менее; здесь есть куча мельчайших деталей, которые мешают базовой идее).
Если вы опустите --index, git stash applyполностью игнорирует iфиксацию.
Если в тайнике есть только две фиксации, git stash applyтеперь можно применить wфиксацию. Он делает это, вызывая git merge2 (не позволяя ему фиксировать или обрабатывать результат как обычное слияние), используя исходный коммит, на котором был создан тайник ( iродительский элемент и wпервый родительский элемент) в качестве базы слияния, wкак --theirscommit, а ваш текущий (HEAD) коммит в качестве цели слияния. Если слияние прошло успешно, все в порядке - ну, по крайней мере, Git так думает - и git stash applyсамо успешно. Если раньше вы применяли git stash popтайник, код теперь отбрасывает тайник. 3 Если слияние не удалось, Git объявляет, что применение не удалось. Если вы использовалиgit stash pop, код сохраняет тайник и выдает то же состояние отказа, что и для git stash apply.
Но если у вас есть третья фиксация - если uв тайнике, который вы применяете, есть фиксация - тогда все меняется! Невозможно сделать вид, что uфиксации не существует. 4 Git настаивает на извлечении всех файлов из этого uкоммита в текущее дерево работы. Это означает, что файлы должны либо не существовать вовсе, либо иметь то же содержимое, что и в uфиксации.
Для этого вы можете использовать git cleanсебя, но помните, что неотслеживаемые файлы (игнорируемые или нет) больше не существуют в репозитории Git, поэтому убедитесь, что все эти файлы могут быть уничтожены! Или вы можете создать временный каталог и переместить туда файлы для безопасного хранения - или даже сделать другой git stash save -uили git stash save -a, поскольку они будут работать git cleanза вас. Но это просто оставляет вам uтайник в другом стиле, с которым вы будете разбираться позже.
+1 Это на самом деле refs/stash. Это имеет значение, если вы создаете ветку с именем stash: полное имя ветки refs/heads/stash, поэтому они не конфликтуют. Но не делайте этого: Git не будет возражать, но вы запутаетесь. :-)
2git stash код на самом деле использует git merge-recursiveпрямо здесь. Это необходимо по нескольким причинам, а также имеет побочный эффект, заключающийся в том, что Git не рассматривает это как слияние при разрешении конфликтов и фиксации.
3 Вот почему я рекомендую избегать git stash popв пользу git stash apply. Вы получаете шанс рассмотреть то , что получил применены, и решить , был ли он на самом деле применяется правильно. В противном случае у вас все еще есть тайник, а это значит, что вы можете использовать его, git stash branchчтобы полностью восстановить все. Ну, при условии отсутствия этой надоедливой uфиксации.
+4 Там действительно должно быть: git stash apply --skip-untrackedчто ли. Также должен быть вариант, который означает перетаскивание всех этих uфайлов фиксации в новый каталог , например git stash apply --untracked-into <dir>, возможно.
git stash show -p | git apply --3