專業工具與問題解決

到目前為止，我們討論的是理想情境：你撰寫程式碼、做提交、建立 Pull Request。但在真實世界中常有狀況不如預期：你可能在程式碼中犯錯、用錯誤的訊息做了提交，或只是意識到方向走偏了。這堂課我們將說明如何解決最常見的問題。

1. Rollback — 在提交前撤銷變更

情境：你修改了檔案，但發現所有更動都不正確，想要快速把檔案還原到最後一次提交後的狀態。

使用 Rollback 功能：

1. 開啟 Commit 分頁。
2. 在清單中找到你想「還原」的變更檔案。
3. 在它上面按滑鼠右鍵並選擇 Rollback。

IDE 會警告你變更將會遺失。確認後，檔案會立刻回到它在 Git 中最後一次儲存的版本。這是撤銷本機變更最簡單且最安全的方法。

2. Reset — 刪除本機提交

情境：你做了一或多個提交，但還沒有做 push。你發現這些提交有誤，想要把它們完全刪除，就像從未發生過一樣。

使用 Reset 功能：

1. 開啟 Git -> Log 分頁以查看提交歷史。
2. 找到你想回到的最後一個「良好」提交（也就是在錯誤提交之前的那個）。
3. 在它上面按滑鼠右鍵並選擇 Reset Current Branch to Here...。

在彈出的視窗中，會請你選擇重置模式。最激烈的是 Hard。

注意！ 模式 Hard 會不可逆地刪除所選提交之後的所有提交，以及那些提交中的所有程式碼變更。請極度小心，只在沒有人看過的提交上使用（尚未推送到 GitHub 的那些）。

3. Push 之後怎麼辦?

情境：你做了 push，才注意到其中有錯。

一旦提交進到遠端伺服器，它就成為專案共同歷史的一部分。試圖重寫這段歷史會給同事帶來巨大問題。想像他們已經抓下你的變更並基於此開始工作。

正確且安全的做法：

直接再做一個修正錯誤的提交並推送即可。這完全是正常的實務做法，如此一來，歷史對所有人都保持真實而清晰。

4. 回看過去：進階使用 Log

我們已經熟悉 Git -> Log 分頁，但它不只是提交清單，而是強大的調查工具。

• 提交雜湊（Commit Hash）：你大概已在日誌中注意到一串字母與數字，例如 a1b2c3d。這個雜湊是唯一的，能精確指向專案歷史中的任何一個時間點。你很少需要手動使用它，但要知道，它就是每個程式碼「快照」的唯一識別碼。
• 你可以依分支、作者、日期，甚至提交訊息中的字詞來篩選歷史。這能幫助你快速找出誰在何時處理了某個功能的部分。
• 想找到新增或刪除某一行程式碼的那次提交嗎？在 Log 視窗中有搜尋欄位，它不僅能搜尋訊息，還能在變更內容本身中搜尋。
• 在程式碼編輯器的邊欄按滑鼠右鍵並選擇 Annotate with Git Blame。IDE 會在每一行旁標示最後一次修改它的人與所屬提交。這對理解為什麼程式碼會被這樣撰寫極為有用。

5. 危險區：Force Push

我們已經說過，修改已推送的提交是個壞主意。但如果你確實改動了本機歷史（例如用 Reset），導致它與伺服器上的歷史不一致呢？當你嘗試做一般的 push 時，Git 會回報錯誤，保護共同歷史不被覆寫。

針對這種情況，有一個選項——force push（強制推送）。這個指令等於告訴伺服器：「把你擁有的一切都忘了。我的本機歷史才是唯一正確的。用我的歷史取代你的。」

警告！ 在 99% 的情況下，在團隊專案中使用 force push 是災難。它可能不可逆地刪除同事已經抓下並基於其工作的提交。這就好比把公共圖書的頁面撕掉，再貼上你自己的。

絕對不能使用 force push 的情況：

• 任何共享分支：main、develop、master。絕對不要。
• 任何除了你之外還有人在使用的分支。

唯一可接受的情境：

你在自己的個人 feature 分支上工作，尚未有人看過或使用。你做了幾個「髒」的提交，把它們推到伺服器後，又想用 Reset 來「整理」它們。在這種情況下，你可以做 force push，以便在建立 Pull Request 之前更新你在伺服器上的分支。

在 IDE 中，此選項通常藏在 Push 按鈕後面。IDE 的開發者刻意如此設計，避免你不小心按到。

如果你沒有 100% 的把握，千萬不要使用 force push。更安全的做法是再建立一個修正的提交。

6. 更新專案

在開始處理新任務之前，務必在 main 分支上按 Update Project。這將避免許多未來的合併衝突，並確保你從最新的程式碼版本開始工作。

1

問卷/小測驗

版本控制，等級 25，課堂 4

未開放

版本控制

Git 入門

開啟