目前位置： 正文

Git 分支已被另一個目錄使用：用 worktree 保留原來的修改

2026-11-03 精品教程 0 0

想在另一個資料夾修網站頁首，執行 git worktree add ../site-copy main 卻看到 main 已被使用的錯誤。這通常不是資料夾權限問題：同一個儲存庫的 main 已在某個工作樹中檢出，Git 預設不讓兩個工作樹同時使用同一條分支。

如果原本的網站目錄還有修改沒做完，不必先清空它。先找出分支在哪個目錄，再決定回去繼續工作，或從指定提交建立另一條修正分支。以下適用已使用 Git 的網站專案；worktree 不會替你部署網站，也不會自動安裝相依套件。

先找出 main 在哪裡，不要只看當前資料夾

在儲存庫的任一工作樹執行：

git worktree list

假設看到以下內容，表示 main 正在 site 目錄使用。實際路徑與提交縮寫會依你的專案而不同：

/projects/site  a1b2c3d [main]

此時再要求一個新目錄檢出 main，Git 會拒絕。若你本來就要改 main，先進入清單中那個目錄，查看 git status --short --branch，確認已有的修改和負責人，再接著處理；不要因為新目錄建立失敗，就把舊目錄刪掉。

要並行修頁首，就建立新分支與新工作樹

如果希望保留原目錄的工作，另開一個修正，先在預定的起點查看目前提交，再建立新工作樹。下面使用尚未存在的目錄名稱與分支名稱：

git log -1 --oneline
git worktree add -b fix/header ../site-header-fix HEAD
git -C ../site-header-fix status --short --branch
git worktree list

-b fix/header 建立新分支；../site-header-fix 是新目錄；最後的 HEAD 表示從目前工作樹檢出的提交開始。HEAD 不代表遠端最新版本，也不代表原目錄裡尚未提交的檔案內容。若需要從另一個已核對的提交開始，應先確認那個提交，再替換最後的起點。

成功後，新目錄的狀態應顯示 fix/header，清單也會多出該路徑。若分支或目錄已存在，先查它是否就是你要接續的工作，或選另一個新名稱；不要用 -B 把既有分支重設成範例起點。

原目錄的未提交修改不會跟過去

例如，main 的 index.html 已改成新頁首但還沒提交，而 HEAD 裡仍是舊頁首。用上述指令建立工作樹後，新目錄會拿到已提交的舊頁首；原目錄的未提交修改仍留在原處。這正是需要分清「從提交建立」與「複製目前資料夾」的地方。

兩個工作樹各有自己的 HEAD、暫存區與工作檔案，但共享儲存庫的物件與一般分支參照。因此它適合並行處理不同分支，不能當成完全獨立的備份。新目錄沒有自動帶入被 Git 忽略的本機設定、上傳檔或安裝好的套件，也不要為了讓測試能跑，就直接把正式環境的密鑰複製進版本控制。

不要先用 force 繞過分支保護

git worktree add 的 force 選項可以放寬部分檢查，但讓同一條分支同時出現在兩個目錄，會增加判斷目前提交與工作狀態的負擔。一般頁面修正先使用不同分支即可，不需要靠強制參數解決。

若清單指向已搬走或暫時無法存取的路徑，先確認那份工作是否還存在，別把「目前看不到目錄」直接當成「可以清掉登記」。新工作樹建好後，回到原目錄再看一次狀態，確認未提交修改仍在；最後提交、合併、推送及部署是另外的步驟，建立工作樹本身不會替你完成。

參考資料

原文鏈接：https://wntheme.com/git-worktree-branch-already-checked-out/，轉載請註明出處。
0

猜妳喜歡

Git log -S漏掉改動？用-G找增刪行
精品教程
Gitgit log程式碼搜尋

想找「哪次提交把timeout從10改成30」，明明看過那筆修改，git log -S 'timeout'卻沒列出來。原因可能不是紀錄消失，而是搜尋條件不同：-S看指定字串在檔案裡的出現次數有沒有變；-G則檢查差異裡新增或刪除的行是否符合正規表示式。 值改了，字串出現次數卻沒變 假設config.txt原本只有一行timeout=10，下一次提交改成timeout=30。兩個版本都只出現一次timeout；因此，以timeout作為-S條件，不會因為數值變動而選出這筆提交。 git log --oneline -S 'timeout' -- config.txt git log --oneline -G 'timeout' -- config.txt 第二條會檢查patch裡的增刪行。因為刪掉的timeout=10、新增的timeout=30都符合timeout，所以-G能找到這次改值。第一條仍可能列出最早新增timeout的提交，不能把「有搜尋結果」誤認為已找到這次修改。 用一個練習庫，看清楚兩組結果 在獨立練習資料夾建立Git儲存庫，先提交config.txt，內容為timeout=10，提交訊息用base；再改成timeout=30，提交訊息用raise timeout；最後補上第二行retry=2，提交訊息用add retry。每次都先git add config.txt再提交。完成後查詢： git log --format=%s -S 'timeout' -- config.txt # base git log --format=%s -G 'timeout' -- config.txt # raise timeout # base git log --format=%s -S 'timeout=10' -- config.txt # raise timeout # base 這裡的註解是預期顯示的提交訊息，不是另一條命令。-S 'timeout=10'能找到raise timeout，是因為完整字串timeout=10從一次變成零次；搜尋timeout時，它仍各出現一次。最後新增retry那筆不符合這些條件，所以不會列出。 找到提交後，再看實際改了哪一行 git log -p -G '^timeout=' -- config.txt # 若已找到要核對的提交，將COMMIT換成它的雜湊 git show COMMIT -- config.txt ^timeout=只比對行首為timeout=的增刪行，能縮小搜尋範圍；-p會把差異一併顯示。選中提交後，核對刪除行、新增行、檔案路徑及上下文，再判斷它是否就是造成問題的修改。這些查詢不會把工作目錄切回舊版。 搜不到時，先檢查條件與範圍...
2026-10-23 52 0
文尼先生 2026-10-23
Git清理預覽沒列出暫存檔？先分清未追蹤與被忽略
精品教程
Gitgit clean忽略規則

想清掉建置暫存檔，先跑git clean -nd，結果清單裡只有筆記，卻沒有build目錄？這通常和忽略規則有關。git clean預設不把被忽略的檔案列入清理範圍；「沒有列出」不代表那個目錄不存在，也不代表工作目錄已經沒有多餘檔案。 先確認你正在看哪個工作目錄 到要檢查的儲存庫根目錄，再執行下面兩行。第一行顯示根目錄路徑，第二行把被忽略的項目也列出來。這裡只盤點檔案，不做刪除。 git rev-parse --show-toplevel git status --short --ignored 短格式中，??代表未追蹤，!!代表被忽略。它們都可能是還沒納入版本紀錄的檔案，但用途不同：被忽略的目錄可能放建置產物，也可能放本機設定或使用者上傳內容。不要只看標記就認定可以刪。 用三種預覽對照忽略規則 以下三行都有-n，只顯示預計處理的項目，不實際移除。-d讓未追蹤目錄也納入檢查；小寫x和大寫X則是兩種不同範圍。 git clean -nd git clean -ndx git clean -ndX 第一行沿用忽略規則；第二行連被忽略的未追蹤檔案也列入；第三行只列被忽略的檔案。這組指令沒有另外指定命令列排除規則，適合先看三者差異。保留-n，別在還沒核清單前換成強制刪除。 用一個小目錄理解輸出 假設儲存庫已追蹤README.md和.gitignore，忽略規則包含build/。目前另外放了一個未追蹤的notes.txt，以及build目錄裡的cache.txt。 在這個例子中，git status --short --ignored會分別以??及!!標示notes.txt和build目錄。git clean -nd預覽notes.txt；加小寫x後也會列出build目錄；改大寫X則只列build目錄。Git的提示語言可能不同，對照檔案路徑和標記即可。 README.md已在索引中，不會因為加了x就變成清理對象。git clean也不是用來還原已追蹤檔案的修改；若問題是改壞了既有程式，要另查差異與還原範圍。 縮小到一個目錄再核對 只想調查build目錄時，把路徑寫在--後面，避免把整個工作目錄的候選項混在一起。下面仍然只是預覽，也會包含該路徑內被忽略的未追蹤檔案。 git clean -ndx -- build/ 先確認build確實是可重建的產物，而且沒有手動放入的重要檔案。若輸出包含.env、uploads、資料庫備份或不認識的路徑，就停下來查用途。被Git忽略，不等於有備份。 預覽清單不是恢復保證 Git沒有追蹤、也沒提交過的檔案，不能指望刪除後從提交歷史找回來。正式清理前先保留需要的資料，再按照確定的路徑範圍操作。若目錄內還有另一個Git儲存庫，也不要為了讓它出現在清理結果而增加強制參數；先弄清楚那是什麼專案。 這篇先做到盤點：確認所在目錄、辨認未追蹤與忽略項目，再比較預覽範圍。清單和預期不同時，查忽略規則與檔案用途，比反覆加強制參數更有幫助。 參考資料 Git官方：git clean的預覽、目錄與忽略範圍 Git官方：git status短格式與忽略項目
2026-10-15 95 0
文尼先生 2026-10-15
Git cherry-pick後少了修改：它不會搬整個分支
精品教程
cherry-pickGit版本控制

功能分支已改好首頁標題，也加了橫幅樣式。你只想先帶回樣式，用了git cherry-pick後，CSS檔出現了，標題卻還是舊文字。這種情況可能是操作符合預期：你挑中的那筆提交只新增CSS，改標題的是前一筆。 cherry-pick會把指定提交所引入的修改套到目前分支。只給一個普通提交時，它不會順便搬走那個分支之前所有提交。先分清「這筆提交改了什麼」與「分支目前包含什麼」，才知道應該挑哪一筆。 做出兩筆分開的修改 下面用一個新建的練習目錄重現。請使用Git Bash，或macOS、Linux的Bash相容shell，逐段執行；PowerShell不能直接照抄這裡的變數與printf語法。目錄名稱要選一個尚不存在的名稱，別在正式網站或已有專案裡執行初始化。 使用者名稱與電郵是練習用假資料，設定只寫進這個repository；關閉換行轉換與提交簽署也只限練習repo。這組例子使用Git 2.47.1 for Windows，沒有連線遠端或推送。mkdir git-pick-demo cd git-pick-demo git init -b codex/main git config user.name Demo git config user.email [email protected] git config core.autocrlf false git config commit.gpgsign false printf '<h1>Original heading</h1>\n' > index.html git add index.html git commit -m "base homepage" git switch -c codex/feature printf '<h1>New heading</h1>\n' > index.html git add index.html git commit -m "A: change heading" printf '.banner { border-radius: 12px; }\n' > banner.css git add banner.css git commit -m "B: add...
2026-10-06 107 0
文尼先生 2026-10-06
Git show讀取commit:file快照
精品教程
Git版本控制

想確認上週提交的設定檔究竟寫了什麼，不必先切換分支，也不用把目前修改暫存起來。Git可以直接讀取某個提交裡的檔案快照。關鍵在冒號：git show COMMIT:path讀的是那個提交保存的檔案內容；git show COMMIT -- path通常顯示提交資訊及該路徑的變更。兩個指令很像，回答的問題卻不同。 先分清完整內容與變更片段 假設page.txt有兩行，第一次提交是old title和footer，第二次只把第一行改成new title。現在工作目錄又改成dirty title，尚未提交。此時至少有三份內容：較早提交、目前HEAD提交，以及磁碟上正在編輯的檔案。查歷史前先決定要讀哪一份，避免看完補丁就誤以為那是整個檔案。 git status --short git log --oneline -- page.txt git show HEAD -- page.txt git show HEAD:page.txt 第三行的雙減號把提交與路徑分開，結果包含diff標頭與加減行，適合回答「這次改了哪裡」。第四行的冒號把提交和樹內路徑接起來，結果只有檔案內容，適合回答「提交當時整份檔案是什麼」。完整快照包含沒有變動的footer；補丁裡看到footer，可能只是差異的上下文，不應據此判斷檔案只剩那幾行。 用提交雜湊指定真正要查的版本 HEAD代表目前檢出的提交，會隨切換分支或新提交而改變。要在問題紀錄或修復筆記中重現同一份檔案，先從git log找到目標提交，記下雜湊，再把範例中的OLD_COMMIT換成那個值。這裡的OLD_COMMIT只是占位文字，不能原樣執行。 git show OLD_COMMIT:page.txt git show HEAD:page.txt 本地隔離案例使用Git 2.47.1.windows.1，建立兩個提交後故意保留未提交修改。第一個提交的快照輸出old title與footer，HEAD快照輸出new title與footer，而工作目錄仍是dirty title與footer。三份內容同時存在，讀取歷史不會把較早版本套到工作目錄，也不會建立新提交。案例沒有遠端，沒有測試推送或正式站設定檔。 # OLD_COMMIT:page.txt old title footer # HEAD:page.txt new title footer # working tree page.txt dirty title footer 冒號後的路徑屬於該提交的目錄樹 使用COMMIT:path時，最容易出錯的是路徑。一般直接寫儲存庫根目錄下的相對路徑，例如HEAD:config/site.json。不要拿電腦的絕對路徑放在冒號後，也不要把網址當成Git路徑。若目前人在子目錄，仍以根目錄相對路徑寫法整理查詢，讓指令放在筆記裡也能讀懂。路徑包含空白時，可以把整個提交與路徑參數用引號包起來。 git show "HEAD:docs/site notes.txt" git ls-tree -r --name-only OLD_COMMIT 第二行列出目標提交中的檔案名稱，適合在記不清舊路徑時先查目錄樹。檔案可能後來才新增，也可能曾經改名。今天的檔名不一定存在於昨天的提交，git show也不會替這個冒號查詢自動追蹤改名。先確認目標提交裡的實際路徑，再取內容，比反覆更換雜湊猜測更可靠。這一步只讀取樹與物件，不改索引。 查不到檔案時先處理版本與路徑 隔離案例另執行git show HEAD:missing.txt，因HEAD裡沒有這個檔案，指令回傳非零退出狀態並顯示路徑不存在的錯誤。這不是空檔案，也不代表歷史被刪掉。若把這種失敗當成成功取到空內容，後續比較或匯出就會得到錯誤結論。先看退出狀態與錯誤訊息，接著用ls-tree確認檔名，必要時重新選擇提交。 提交識別本身也可能錯誤。從別人的問題描述複製短雜湊時，先確認自己的儲存庫具有該提交；不同儲存庫的短雜湊不能當成相同版本的保證。若目標物件未在本地，這篇只讀查詢不會自行補齊遠端資料。需要另行取得資料時，應按自己的遠端與權限處理，不能拿查詢失敗推論正式站版本不存在。 把查到的內容放回問題脈絡 例如網站的設定在某次發布後出現異常，先查那次發布實際使用的提交，不要只因主分支現在沒有問題就認定當時也相同。讀取設定檔快照只能證明儲存庫記錄的內容；它不會證明部署機當時載入了哪個環境變數，也不會證明程式重新啟動過。若問題涉及部署，還要另核發布紀錄與執行環境。這些資訊不能從一份Git快照推算出來。...
2026-10-05 60 0
文尼先生 2026-10-05
Git改名後查不到舊紀錄：log follow怎麼追單一檔案
精品教程
Git版本控制

把文章檔案改名後，對新路徑跑git log只看到改名那次，以為先前的修改紀錄不見了。先看查詢是不是只按新路徑篩選：較早提交裡檔案還叫舊名字。Git log的--follow可以在單一檔案的歷史查詢裡繼續追過改名，但它不是替所有檔案建立永久身分證。 路徑篩選與完整提交歷史不同 git log --oneline -- new-name.txt 這段查的是與new-name.txt路徑相關的歷史，並不是整個儲存庫所有提交。雙連字號把修訂參數與路徑分開，避免同名分支或其他參數混淆。文件如果以前叫old-name.txt，只查新名稱就可能沒有列出舊路徑的變更。 不要為了讓畫面出現舊紀錄，就立刻恢復舊檔名或重新提交。先用只讀查詢核對改名前後的路徑，以及改名提交到底做了什麼。歷史查詢的顯示範圍與檔案是否仍存在，是兩個不同問題。 用純改名案例核對follow 本次使用Git 2.47.1的新隔離儲存庫，沒有遠端，也沒有對產品儲存庫執行命令。先建立old-name.txt並提交，再增加一行與第二個提交，最後只把路徑改成new-name.txt，不修改正文。這讓Git辨認到百分之百相似的純改名，避免把內容大改與改名混在同一次觀察裡。 git mv old-name.txt new-name.txt git commit -m "rename only" git log --format=%s -- new-name.txt git log --follow --format=%s -- new-name.txt 只查新路徑時，輸出只有rename only。加--follow後，輸出依序是rename only、edit old file、create old file。三個訊息與新儲存庫實際建立的三個提交對應，不是補寫到log裡的示範文字；案例保存每個命令與原始輸出，可直接核對。 --format=%s在這裡只列提交訊息標題，是為了讓差異容易讀。它不改變要追查的提交集合，也不能單憑相同訊息就證明是同一個提交。真實排查可用--oneline或包含完整hash的格式，將觀察結果與確切提交對上。 確認改名提交，而不是只相信檔名 git show --summary HEAD 案例的摘要顯示old-name.txt改成new-name.txt，括號是100%。這代表本次Git的改名偵測結果，把這兩個路徑視為相同內容的改名。它不是說所有未來修改都必然追得回來，也不是Git在每次提交時永遠保存了一個不變的檔案編號。 Git以提交快照與比較來判斷改名關係。若同一次提交既改路徑又大量重寫內容，相似度與偵測設定就可能影響結果。此時先查看實際diff與改名摘要，再決定是否需要調整查詢選項；不能拿這個純改名成功的案例，保證完全重寫的檔案也一定被識別。 git mv會更新工作目錄並協助更新索引，但仍需要提交才能形成這次歷史。它不是在背景為檔案增加永久追蹤標籤。本例先提交改名，再查詢新路徑；沒有把尚未提交的移動當成已存在的歷史節點。 follow用在單一檔案，不是整個目錄 Git log文件對--follow明確限定單一檔案。複雜合併情況仍應核對具體提交關係。查資料夾、多個路徑或複雜合併時，不要只加同一個選項就宣稱完整追蹤。本例是線性的三個提交、一個檔案，沒有合併、複製或拆成多檔的情境。 先選你要讀的那個路徑，核對它在目前提交中的實際拼寫與大小寫。路徑相對於你執行命令的位置時，也要確認目前目錄。檔名若含空白，使用引號保護整個路徑參數，不能把空白拆成兩個檔案條件。本文使用簡單名稱，沒有把其他平台的大小寫行為當成實測。 如果要從指定歷史起點往回找，可明確指定已經核對的提交，再接雙連字號與路徑。修訂表示式決定從哪裡走，路徑決定篩選什麼；兩者都對上，結果才有可重現的範圍。不要看到查詢空白就猜測整個儲存庫的紀錄已經被刪除。 要讀舊版本正文，另用確切路徑與提交 log回答哪些提交影響這條歷史；show可以進一步查看某個提交的變更或物件。選出一筆舊提交後，要讀其檔案正文，仍應使用該提交當時存在的路徑。新名稱在舊提交裡可能不存在，不能因為follow找得到提交，就假設新路徑也已存在於那個快照。 這篇只實測log的篩選與純改名摘要，沒有執行恢復舊版本、覆蓋當前檔案或重設分支。這些修改工作目錄的操作與只讀歷史不同。如果目標只是查看舊內容，先停在只讀查閱，不必把現在的文件改回去。 用三個輸出驗收改名歷史 這些查閱命令不會新增提交，也不會把舊名稱重新放回工作目錄。案例最後仍只有新名稱的檔案，status乾淨；讀完歷史再核一次工作狀態，就能確認查詢沒有混入其他編輯操作。 先保存一般路徑log，確認它只列rename only；再保存follow的三個提交訊息；最後用show摘要核對100%純改名。三項互相支持，才能解釋為什麼較早提交會沿著舊名稱出現。只截一張三行log，沒有改名上下文，仍不足以知道查詢用的是哪個路徑與起點。 真實檔案可以再核對改名前一筆的舊路徑，確認當時確有你要找的內容。這一步用來排除同名不同檔案或選錯提交，不是要求每次都手動遍歷所有歷史。先用follow縮小範圍，再對關鍵提交核對內容，通常比直接猜測哪個檔名曾經存在更清楚。 如果輸出沒有預期的舊紀錄，保留Git版本、目前提交、新舊路徑與相關改名diff。檢查資料是否存在於你當前的本地儲存庫、查詢起點是否正確，以及改名是否被識別。本例沒有淺克隆或遠端資料取得，不能把本地查詢失敗解釋成遠端一定沒有那些提交。 讀歷史時也別把提交日期順序當成所有操作的完整故事。這個小案例沒有分支合併，三筆直接連成一條線；真專案的歷史圖可能不是線性。文件已限定--follow用在單一檔案，遇到複雜情況要核對具體提交關係，避免把工具輸出的簡化路徑說成唯一真實演變。 檔名改了，歷史不一定斷了；但可追查的結果來自明確的路徑、提交與改名偵測。把這三個條件保存，再用單檔follow核對，才能找到舊內容的入口，而不會為了看歷史就改動現在的工作。 參考資料Git：路徑查詢與followGit：改名與相似度偵測Git：提交摘要與物件Git：移動檔案與索引Git：修訂與路徑表示
2026-10-05 52 0
文尼先生 2026-10-05
Git切到舊提交進入detached HEAD：把新提交留在分支
精品教程
Git版本控制

切到舊提交查看程式，Git顯示detached HEAD。若只是看歷史，這個狀態很正常；但如果你在這裡改了檔案並提交，先把新提交接到有名字的分支，再切回其他工作。提交已經產生，不代表原本main會跟著移到它。 HEAD直接指向提交，與跟著分支不同 平常HEAD跟著某個分支，新增提交時分支也會往前。detached HEAD時，你目前站在某個提交上，沒有讓既有分支一起前進。可以修改、測試與提交，但這些新工作需要另有名稱留住，才能方便下一次找到。 不要把這個狀態理解成檔案已經丟失或儲存庫壞掉。Git只是把「目前看的提交」與「目前所在的分支」分開了。先確認是不是刻意切到提交或標籤，再決定只看完離開，還是保存這裡的新工作。 git status git branch --show-current git log -1 --oneline 在detached狀態，branch --show-current沒有分支名稱輸出；log仍能看到當前提交。兩個命令回答不同問題，所以不要因為分支名稱空白就以為沒有HEAD，或因為log有提交就以為已經在main。 用新儲存庫建立真實對照 本次案例使用Git 2.47.1與新的隔離儲存庫，沒有遠端，也沒有在產品儲存庫做任何切換。main先有base與main second兩個提交，再切回base，進入detached狀態；這讓分支最新版本與當前查看的舊版本能清楚區分。 git switch --detach BASE_COMMIT BASE_COMMIT是你已經核對的完整或可辨識提交hash，範例字樣要換成自己的提交，不要照字面執行。案例用rev-parse保存base的真hash再傳入命令，沒有假造一個hash。切換前也確認工作狀態，避免把尚未保存的其他修改混進這個實驗。 切換可能更新工作目錄與索引。Git通常會阻止導致本地修改丟失的切換，但不代表你應跳過盤點；本文沒有加--force或--discard-changes。若命令因修改而拒絕，先處理自己的工作，不要為了進入舊版本就強制丟棄它們。 在detached狀態提交，再立即建立分支 案例把note.txt改成detached work後，暫存並提交。新commit的hash在建立分支前就已保存；這一步讓我們知道接下來命名的究竟是不是剛產生的提交。不要只根據檔案看起來相同就判定分支接對了。 git add note.txt git commit -m "detached work" git rev-parse HEAD git switch -c save-detached -c建立新分支並切換到它，沒有另指定起點時以目前HEAD為起點。這次save-detached直接指向剛才的detached work提交，沒有重新提交或複製檔案。本次建立分支前後的HEAD hash完全相同，只有它現在也能由分支名稱找到。 選一個尚未存在的分支名稱。如果名稱已經存在，先核對它指向什麼，換一個清楚的名稱；不要為了避免錯誤把-c改成-C。大寫-C有重設已有分支的用途，範圍與這篇保留新工作不同，不能當作大小寫都一樣。 核對名稱、提交與歷史三者 讀歷史時可以先用三個名稱理解關係：base是共同起點，main second是原分支第二筆，detached work則是從base另走的一筆。新分支保存的是這條旁路，不會把兩筆新提交排序後拼成一條直線。想把新工作整合回main，是後續合併或其他整合操作，不能靠取分支名稱就視為完成。 git branch --show-current git rev-parse HEAD git log --oneline --decorate --all 本次show-current回傳save-detached，HEAD hash仍是detached work那筆；帶--all的紀錄同時看得到main的main second與新分支的detached work。兩條路都從base開始，這不是把main移回舊版本，也不是將兩條分支自動合併。 在案例裡，最後工作目錄乾淨，note.txt是detached work內容，分支名稱明確。若你自己的工作還有未提交修改，建立分支只是給目前提交命名，不會把那些修改自動變成提交；需要另外檢查status並決定下一步。 分支是本地名稱，不等於已經上傳到GitHub，也不等於完成部署。這個案例沒有任何遠端操作，所以只驗證本地提交可由save-detached找到。要分享時，應另核對遠端與推送權限，不把本地成功冒充外部保存。 如果已經切走，先查reflog再決定 Git的reflog記錄本地引用與HEAD曾經移動的位置，可以協助尋找剛才的提交。但它不是永久備份，紀錄與不可達物件有保留與清理規則。這篇沒有先切走再找回的實測，不能把它說成任意時間都能恢復任何工作。 如果已經離開detached狀態，先只讀git reflog與提交內容，確認哪一筆才是自己的工作，再按核對過的提交建立新分支。不要看到一個相近時間的hash就直接重設main，因為分支指向與恢復檔案內容是不同操作。已知提交hash時，給它另取名稱通常更容易核對。 未提交修改與已經提交的工作也要分開。reflog記的是引用移動，不是替每次鍵盤輸入保存完整歷史；沒有commit的內容不能直接沿用「找提交hash」的做法。回到編輯器或自己的備份核對範圍，別讓一種恢復命令承擔它沒有紀錄的資料。 把保存動作放在離開之前 如果只是打算試改，進入舊提交時也可以直接建立實驗分支，讓後續提交一開始就有名稱。本文先進入detached再建立分支，是為了重現已經發生的情況；不是要求每次看歷史都必須繞這條路。是否要改檔與是否要保留成果，決定了合適的入口。 也要確認分支名稱不是遠端名稱的混用。這份儲存庫只有本地main與save-detached，沒有origin或追蹤設定，所以命令的效果很清楚。真實專案若有工作樹或同名分支，先查現況；建立新名稱仍應以剛才核對的提交為準。...
2026-10-05 47 0
文尼先生 2026-10-05
顯示驗證碼
沒有帳號？註冊  忘記密碼？