面試實戰筆記：Git 版本回退與單向鏈表節點刪除技巧

前言

工作一年多，技術增長緩慢，近期面試總結出兩道經典高頻題：Git 版本回退衝突處理、單向鏈表無頭指針刪除當前節點。記錄思路與標準答案，供後續複盤。

一、Git 版本回退與團隊協作衝突解決

1.1 場景描述

提交歷史：A → B → C（當前 HEAD）。需回退到版本 A，並推送到遠程倉庫，其他開發者已拉取 C 版本。

1.2 標準操作流程

# 1. 本地硬回退到版本 A
git reset --hard <commit-id-of-A>

# 2. 強制推送到遠程（覆蓋歷史）
git push -f origin <branch-name>

1.3 衝突根因與解決

現象：其他開發者再次 git pull 時會報錯，提示「非快進」或歷史分歧。

原因：遠程歷史被重寫，本地仍有 C 提交，Git 拒絕合併不相關歷史。

解決方案（由團隊協商統一）：

1. 方案 A（推薦，歷史整潔）：其他開發者執行 git fetch origin && git reset --hard origin/<branch>，強制同步遠程歷史，丟棄本地未推送提交。
2. 方案 B（保留本地工作）：git pull --rebase 或手動 cherry-pick 自己未推送的提交到新基線上。
3. 方案 C（避免強推）：使用 git revert <commit-id-of-C> ... <commit-id-of-B> 創建反向提交，歷史不重寫，無衝突風險。

1.4 面試加分點

• 區分 reset --soft/mixed/hard 對工作區、暫存區、HEAD 的影響。
• 說明 push -f 風險：團隊協作中嚴禁對公共分支強推，除非協同清理。
• 提及 reflog 可恢復誤操作的提交。

二、單向鏈表刪除當前節點（無前驅指針）

2.1 題目

給定單向鏈表節點 B（非尾節點），無法訪問頭節點 A，僅持有 B 的引用，如何刪除 B？

2.2 錯誤直覺

嘗試修改 A 的 next 指向 C。但無法訪問 A，不可行。

2.3 標準技巧：數據前移法

核心思想：將下一節點 C 的數據複製到 B，然後刪除 C。邏輯上等價於刪除 B。

public void deleteNode(ListNode node) {
    // 前提：node 非尾節點
    ListNode next = node.next;
    node.val = next.val;      // 複製數據
    node.next = next.next;    // 跳過 next
    // next 成為垃圾對象，等待 GC
}

2.4 圖示演示

最終鏈表：A → B'(原C數據) → D。原 B 數據被覆蓋，原 C 節點被跳過。

2.5 邊界條件與局限

• 必須非尾節點：尾節點無 next 可複製，需遍歷或維護前驅指針。
• 外部引用問題：若其他引用指向原 C 節點，該引用將變為「懸空」或訪問到已邏輯刪除的節點。
• 對象身份改變：節點 B 的內存地址未變，但業務數據已替換。若業務依賴對象身份（如 == 比較、作為 Map Key），會出現邏輯錯誤。

2.6 面試延伸：雙向鏈表如何刪除？

直接操作 node.prev.next = node.next; node.next.prev = node.prev;，O(1) 且無數據複製副作用。

三、總結與反思

1. Git 回退是雙刃劍，團隊必須建立分支策略（Git Flow / Trunk Based）與提交規範，減少強推場景。
2. 鏈表刪除技巧體現「空間換時間、邏輯等價替換」的算法思想，但需警惕副作用。
3. 面試中遇到不會的題目，誠實說明思路，追問細節，展示學習態度比死記答案更重要。