「先還原」「先重來」類退出指令的處理
「先還原」「先重來」類退出指令的處理
B：
C：
核心原則
退出指令（「先還原」「先重來」「先放著」）的執行前要先確認兩件事：還原到哪個狀態、要不要先存 checkpoint。 直接刪掉當前進度、未來想比較沒得比、想恢復也找不到。
為什麼退出指令需要 protocol
商業邏輯
退出指令的字面意思是「拿掉現在做的東西」、但背後通常有更複雜的意圖：
| 字面 | 可能的真實意圖 |
|---|---|
| 「先還原」 | 暫時不用、之後可能重做 |
| 「先還原」 | 完全放棄、不會再做 |
| 「先還原」 | 換個方向重做 |
| 「先重來」 | 從上一個 commit 重新試 |
| 「先重來」 | 從更早的點重新試 |
執行者不確認意圖、直接刪 = 把使用者的選項收窄成「沒有了」。事先確認 = 為使用者保留可能性。
這次任務的實際情境
觀察
使用者說：「如果要做到這麼大的複寫原設計、我們先還原回去、先不要做這個變更」。
我立刻刪掉那段 CSS、繼續往下做其他事。沒問「還原到哪」、沒先 commit checkpoint。
判讀
後來想比較「複雜覆寫版本」與「接受原設計版本」的差異 — 沒得比。「複雜覆寫版本」已經不存在於 git 歷史。
正確流程應該是：
- 收到「還原」指令時、先回應「我會先 commit 當前進度（即使未採用）作為 checkpoint，再還原到 X 狀態。OK 嗎？」
- 確認後、commit 當前狀態（不 push）、commit message 標明「探索版本、未採用」
- 還原到 X 狀態
- 繼續做後續事
未來想比較或恢復、checkpoint 都還在。
執行：退出指令的 protocol
收到退出指令時、依序處理：
| 步驟 | 動作 |
|---|---|
| 1 | 暫停執行、不要立刻刪 |
| 2 | 確認「還原到哪個狀態」（上個 commit / 特定 commit / 完全乾淨） |
| 3 | 評估「當前進度有保留價值嗎」 — 探索成果、未採用方案、可能未來重用 |
| 4 | 有保留價值 → 先 commit checkpoint、message 標明「探索、未採用」 |
| 5 | 執行還原（reset / checkout / revert） |
| 6 | 確認還原後狀態符合使用者意圖 |
Checkpoint 的命名與 commit message
當前進度作為 checkpoint commit、message 應該包含：
1chore(explore): N+1 attempts to remove disclosure marker
2
3探索方向：用 ::-webkit-details-marker / ::marker / display: block 三層
4覆寫移除 disclosure 三角圖示。
5寫了 5 條 CSS 跨 3 種瀏覽器、覆寫成本過高。
6
7最終決定：接受原設計、不採用此方向。
8此 commit 保留探索成果、未來若評估值得做時可參考。關鍵元素：
chore(explore):prefix — 標明非正式採用- 探索方向 — 說明做了什麼
- 最終決定 — 為什麼不採用
- 保留理由 — 未來何時可能重用
未來人看到這個 commit、知道「這是探索、不是當前實作」、不會誤用。
內在屬性比較：四種退出處理
| 處理 | 可逆性 | 比較成本 | 適用情境 |
|---|---|---|---|
| 直接刪、不留紀錄 | 最低 — 永久失去 | 不可比較 | 不適用 |
git reset --hard（未 commit 直接丟） | 低 — git reflog 短期還在 | 困難 | 確定不要 |
git stash（暫存到 stash） | 中 — stash 可隨時恢復 | 中 | 短期暫停 |
git commit checkpoint 後 reset / revert | 高 — commit 永久存在 | 容易 | 探索性嘗試、未採用方案 |
優先選 checkpoint 方式 — 為未來保留比較與恢復的可能性。
退出意圖的辨識
從語氣判斷
| 語氣 | 對應意圖 | 推薦處理 |
|---|---|---|
| 「先還原」 | 暫時、可能重做 | Checkpoint + 還原 |
| 「先還原、不要做了」 | 確定放棄 | Checkpoint（小機率重看） + 還原 |
| 「重來」 | 換個方向 | Checkpoint + 還原到起點 |
| 「不要這樣寫」 | 局部修正、不是全還原 | 局部改、不要全還原 |
不確定就問。「不要這樣寫」這類指令容易被理解成「全還原」、實際只是「這段重寫」。
確認意圖的問法
1你想要：
2 □ 完全還原、刪掉這次的 CSS
3 □ 還原但保留 commit checkpoint、未來可能參考
4 □ 局部修正（哪一段保留、哪一段重寫）
5
6或是其他？設計取捨：退出指令的處理策略
四種做法、各自機會成本不同。這個專案選 A（Checkpoint + 確認還原範圍）當預設、其他做法在特定情境合理。
A：Commit checkpoint + 確認還原範圍（這個專案的預設）
- 機制：commit 當前進度（標明「探索、未採用」）+ 問「還原到哪個 commit」+ 執行還原
- 選 A 的理由：未來想比較或恢復都還在、checkpoint 成本只是多一個 commit
- 適合：探索性嘗試、未採用方案的退出
- 代價：多一個 commit 在歷史中（可後續 squash 或保留）
B：git stash 暫存
- 機制：把未 commit 的變更存到 stash、不污染 commit 歷史
- 跟 A 的取捨：B 不留 commit、A 留 commit；B 適合「短期暫停、之後恢復」、A 適合「長期探索紀錄」
- B 比 A 好的情境：暫時切到別的工作、之後一定會回來繼續
C：git reset --hard（直接丟）
- 機制：reset 到指定 commit、未 commit 的變更全失去
- 跟 A 的取捨：C 完全清乾淨、A 保留紀錄；C 在 git reflog 內短期還能恢復、但之後永久消失
- C 才合理的情境：確定不要的探索、且確認不需要未來參考
D：直接刪檔案、不留 git 紀錄
- 機制：手動刪 / 改、不 commit
- 成本特別高的原因：未來想比較或恢復都做不到、使用者選項被收窄
- D 是反模式：git 是免費的紀錄工具、不用反而是浪費 — 未來想比較或恢復都做不到、使用者選項被收窄
判讀徵兆
| 訊號 | 應該觸發的處理 | 第一個該做的事 |
|---|---|---|
| 「先還原」 | 確認還原範圍 + checkpoint | 問「還原到哪」 |
| 「重來」 | 確認重做起點 + checkpoint | 問「從哪重來」 |
| 「不要做了」 | 評估保留價值 | 探索成本高就 checkpoint、否則直接刪 |
| 「先放著」 | Stash 或 branch 保留 | 不要刪、要留可恢復路徑 |
| 「換個方法試試」 | Checkpoint + 換方向 | 保留現方法的進度 |
核心原則：退出指令的執行不該收窄使用者的未來選項。Checkpoint = 給未來保留可能性、成本只是多一個 commit。