English ▾ 主題 ▾ 最新版本 ▾ git-restore 最後更新於 2.55.0

名稱

git-restore - 還原工作目錄中的檔案

概要

git restore [<options>] [--source=<tree>] [--staged] [--worktree] [--] <pathspec>…​
git restore [<options>] [--source=<tree>] [--staged] [--worktree] --pathspec-from-file=<file> [--pathspec-file-nul]
git restore (-p|--patch) [<options>] [--source=<tree>] [--staged] [--worktree] [--] [<pathspec>…​]

描述

使用還原來源中的某些內容，還原工作目錄中指定的路徑。如果某個路徑已被追蹤，但還原來源中不存在該路徑，則會將其刪除以符合來源狀態。

此指令也可搭配 --staged 來還原索引（index）中的內容，或搭配 --staged --worktree 同時還原工作目錄與索引。

預設情況下，如果指定了 --staged，則內容會從 HEAD 還原；否則會從索引還原。請使用 --source 從不同的提交（commit）進行還原。

請參閱 git[1] 中的「重設 (Reset)、還原 (restore) 與復原 (revert)」以了解這三個命令之間的差異。

選項

-s <樹狀物件>
--source=<樹狀物件>

使用給定樹狀物件中的內容還原工作目錄檔案。指定來源樹狀物件的常見做法是透過與其相關聯的提交、分支或標籤名稱。

若未指定，則在給定 --staged 時從 HEAD 還原，否則從索引還原。

作為特殊情況，如果只有一個合併基礎（merge base），您可以使用 "<修訂版-A>...<修訂版-B>" 作為 <修訂版-A> 和 <修訂版-B> 合併基礎的捷徑。您可以省略 <修訂版-A> 或 <修訂版-B> 其中之一（最多一個），此時預設為 HEAD。

-p
--patch

以互動方式選擇還原來源與還原位置之間差異的區塊（hunks）。請參閱 git-add[1] 的「互動模式（Interactive Mode）」章節以了解如何操作 --patch 模式。

-U<n>
--unified=<n>

產生帶有 <n> 行前後內容的差異。前後內容行數預設為 diff.context，如果未設定配置變數則為 3。（由於歷史意外，不帶 <n> 的 -U 會被默默接受為 -p 的同義詞）。

--inter-hunk-context=<n>

顯示差異修改塊之間的內容，最多到指定的 <n> 行，從而融合彼此接近的修改塊。預設為 diff.interHunkContext，如果未設定配置選項則為 0。

-W
--worktree
-S
--staged

指定還原位置。如果未指定任何選項，則預設還原工作目錄。指定 --staged 將僅還原索引。兩者同時指定則兩者皆還原。

-q
--quiet

靜默模式，抑制回饋訊息。隱含 --no-progress。

--progress
--no-progress

當標準錯誤串流連接到終端機時，預設會報告進度狀態，除非指定了 --quiet。無論是否指定 --quiet，此旗標都會啟用進度報告，即使未連接到終端機也是如此。

--ours
--theirs

當從索引還原工作目錄中的檔案時，針對未合併（unmerged）的路徑使用暫存區 #2（ours）或 #3（theirs）。當從樹狀物件檢出路徑（即使用 --source 選項）時，無法使用此選項。

請注意，在 git rebase 和 git pull --rebase 期間，ours 和 theirs 可能會互換。詳情請參見 git-checkout[1] 中對相同選項的說明。

-m
--merge

當從索引還原工作目錄中的檔案時，針對未合併的路徑重建衝突的合併狀態。當從樹狀物件檢出路徑（即使用 --source 選項）時，無法使用此選項。

--conflict=<樣式>

與上面的 --merge 選項相同，但會更改衝突修改塊的呈現方式，覆蓋 merge.conflictStyle 配置變數。可能的值為 merge（預設）、diff3 和 zdiff3。

--ignore-unmerged

當從索引還原工作目錄中的檔案時，若存在未合併的條目，且未指定 --ours、--theirs、--merge 或 --conflict，則不會中斷作業。工作目錄中未合併的路徑將保持原樣。

--ignore-skip-worktree-bits

在稀疏檢出（sparse checkout）模式下，預設僅更新符合 <路徑規格> 以及 $GIT_DIR/info/sparse-checkout 中稀疏模式的條目。此選項會忽略稀疏模式，並無條件還原 <路徑規格> 中的所有檔案。

--recurse-submodules
--no-recurse-submodules

如果 <路徑規格> 指向一個活躍的子模組（submodule），且還原位置包含工作目錄，則只有在給定此選項時才會更新子模組。在這種情況下，其工作目錄會被還原到父專案中記錄的提交，且任何本地修改都將被覆蓋。若未指定（或使用 --no-recurse-submodules），子模組的工作目錄將不會被更新。與 git-checkout[1] 一樣，這會使子模組的 HEAD 處於分離狀態（detached）。

--overlay
--no-overlay

在覆蓋模式（overlay mode）下，還原時永不刪除檔案。在非覆蓋模式下，刪除那些未出現在 --source=<樹狀物件> 之 <樹狀物件> 中的已追蹤檔案，以使其精確符合該 <樹狀物件>。預設為非覆蓋模式。

--pathspec-from-file=<檔案>

路徑規格（pathspec）透過 <file> 傳遞，而不是透過命令列參數。如果 <file> 正好是 -，則使用標準輸入。路徑規格元素由 LF 或 CR/LF 分隔。路徑規格元素可以依照配置變數 core.quotePath 的說明進行引號處理（見 git-config[1]）。另請參閱 --pathspec-file-nul 和全域的 --literal-pathspecs。

--pathspec-file-nul

僅在使用 --pathspec-from-file 時有意義。路徑規格元素由 NUL 字元分隔，所有其他字元都按字面意思解釋（包括換行符和引號）。

--

不要將後續的任何參數解釋為選項。

<路徑規格>...

限制受操作影響的路徑。

更多詳情請參閱 gitglossary[7] 中的 pathspec 項目。

範例

以下順序會切換到 master 分支，將 Makefile 還原到兩個修訂版本前，錯誤地刪除了 hello.c，然後從索引中將其找回。

$ git switch master
$ git restore --source master~2 Makefile  (1)
$ rm -f hello.c
$ git restore hello.c                     (2)

  1. 從另一個提交中取出檔案

  2. 從索引還原 hello.c

如果您想還原所有 C 原始碼檔案以符合索引中的版本，您可以執行：

$ git restore '*.c'

請注意 *.c 周圍的引號。即使 hello.c 不再存在於工作目錄中，它也會被還原，因為萬用字元（globbing）是用於匹配索引中的條目（而非 Shell 在工作目錄中進行匹配）。

還原當前目錄中的所有檔案：

$ git restore .

或使用 top 路徑規格魔法（參見 gitglossary[7]）還原所有工作目錄檔案：

$ git restore :/

將索引中的檔案還原以匹配 HEAD 中的版本（這與使用 git-reset[1] 相同）：

$ git restore --staged hello.c

或者您可以同時還原索引和工作目錄（這與使用 git-checkout[1] 相同）：

$ git restore --source=HEAD --staged --worktree hello.c

或是更實用但可讀性較低的縮寫形式：

$ git restore -s@ -SW hello.c

參見

git-checkout[1], git-reset[1]

GIT

git[1] 套件的一部分