Git與代碼審查：Pull Request的完整流程與規範

在團隊協作開發中，代碼的“流轉”和“質量”是關鍵。想象一下，如果你和隊友各自寫代碼，最後突然把所有文件混在一起提交，很容易出問題——這時候，Git和Pull Request（PR）就是解決這個麻煩的利器。今天我們就從最基礎的概念開始，一步步瞭解Git如何幫我們管理代碼，以及PR如何成爲團隊協作的“橋樑”。

一、先聊聊Git基礎：爲什麼它是協作的核心？¶

在講PR之前，我們需要簡單回顧幾個Git的核心操作，它們是理解PR流程的基礎：

1. 分支（Branch）：並行開發的“舞臺”¶

分支就像不同的“舞臺”，每個開發者可以在自己的分支上寫代碼，互不干擾。比如你要開發一個新功能，就從主分支（通常叫main或master）創建一個新分支（比如feature/user-login），在這個分支上獨立開發。
操作命令：

  # 從主分支創建新分支
  git checkout main  # 先切換到主分支
  git pull origin main  # 拉取主分支最新代碼
  git checkout -b feature/user-login  # 創建並切換到新分支

2. 提交（Commit）：保存代碼的“快照”¶

提交（Commit） 是把你寫好的代碼“快照”存到Git裏，每次提交都要寫一個清晰的提交信息（比如“fix: 修復登錄按鈕樣式問題”），方便自己和隊友回顧修改歷史。
操作命令：

  # 修改代碼後，把更改提交到本地分支
  git add .  # 把所有修改過的文件加入暫存區
  git commit -m "fix: 修復登錄按鈕無法點擊的問題"  # 提交到本地分支

3. 推送（Push）：把代碼“推”到遠程倉庫¶

本地分支寫好代碼後，需要把它推到團隊共享的遠程倉庫（比如GitHub、GitLab），讓其他人也能看到。
操作命令：

  git push origin feature/user-login  # 推送到遠程倉庫的對應分支

二、代碼審查（Code Review）和Pull Request（PR）：協作的“紅綠燈”¶

1. 爲什麼需要代碼審查？¶

發現問題：隊友幫你檢查代碼，能更早發現bug、邏輯漏洞或性能問題。
保證質量：避免“自己寫的代碼自己改”，通過集體審查讓代碼更健壯。
知識共享：新成員能快速瞭解項目架構，老成員也能學習新功能的實現思路。

2. 什麼是Pull Request（PR）？¶

PR是開發者向團隊倉庫提交代碼的“請求”，簡單來說：你完成了一個功能或修復後，通過PR告訴團隊“我寫好了，你看看能不能合併到主分支？”。

PR的本質是“協作的橋樑”：
- 你提交PR → 團隊成員審查 → 團隊討論 → 確認沒問題後合併到主分支。

三、PR的完整流程：從代碼寫完到合併的“通關攻略”¶

以常見的GitHub/GitLab平臺爲例，PR流程可以分爲以下6個步驟：

步驟1：準備工作——確保代碼“乾淨且最新”¶

在提交PR前，要做好兩件事：
- 拉取主分支最新代碼：避免你的分支和主分支“脫節”，產生衝突。

  git checkout main  # 切換到主分支
  git pull origin main  # 拉取主分支最新代碼
  git checkout feature/user-login  # 返回自己的分支
  git merge main  # 把主分支的更新合併到自己的分支（或用rebase避免多次提交）

規範提交信息：提交信息要簡潔明確，比如：
✅ 好的：fix: 登錄頁面加載緩慢問題
❌ 差的：改了個bug（沒人知道你改了啥）
推薦用約定式提交規範，格式通常是：類型: 簡短描述，類型包括fix（修復）、feat（新功能）、docs（文檔）等。

步驟2：推送分支到遠程倉庫¶

寫完代碼並檢查無誤後，把本地分支推到遠程倉庫，讓團隊能看到你的代碼：

git push origin feature/user-login  # 推送到遠程倉庫的feature分支

步驟3：在平臺上創建PR¶

在代碼託管平臺（如GitHub）的倉庫頁面，點擊“Pull requests” → “New pull request”，然後：
- base分支：選擇目標分支（通常是main或develop）。
- compare分支：選擇你剛推送的分支（比如feature/user-login）。
- 點擊“Create pull request”，進入PR的創建頁面。

步驟4：填寫PR信息——讓審查者“一眼看懂”¶

PR的描述是“溝通的窗口”，必須清晰說明以下內容（可以用模板）：

PR描述模板示例：¶

## 🔍 爲什麼要做這個修改？
（比如：修復用戶登錄時的驗證碼問題，或新增用戶註冊功能）

## 🚀 實現的功能/修復的問題
- 新增了“記住密碼”選項（勾選後30天免登錄）
- 修復了驗證碼圖片刷新失敗的bug

## 🧪 測試情況
- 本地測試：在Chrome、Firefox瀏覽器均驗證通過
- 邊界測試：連續點擊“登錄”10次，未出現崩潰
- 截圖：[可選，放功能界面截圖]

## 🚨 注意事項
- 依賴後端接口：已同步後端同學確認API格式
- 潛在風險：暫無明顯風險（如有可補充）

關鍵要點：¶

修改目的：一句話說清楚“你爲什麼做這個PR”。
測試結果：告訴審查者“你的代碼是可驗證、可運行的”。
關聯問題：如果項目用了Issue跟蹤（比如Jira、GitHub Issues），直接關聯Issue號（如#123），方便團隊追溯。

步驟5：等待代碼審查（Code Review）¶

提交PR後，平臺會自動或手動分配審查者（比如團隊裏的負責人或資深開發者）。審查者會檢查：
- 功能是否正確：是否符合需求？
- 代碼質量：有沒有冗餘代碼？命名是否清晰？邏輯是否合理？
- 潛在風險：是否有性能問題、安全漏洞（比如SQL注入）？

審查者的常見反饋：¶

✅ 批准（Approved）：代碼沒問題，可合併。
🚧 請求修改（Request changes）：需要你修改某些細節，比如“變量名建議改得更清晰”。
❌ 拒絕（Comment）：如果問題嚴重（比如架構有問題），可能需要重新設計。

開發者如何應對反饋？¶

收到修改意見後，在本地分支繼續修改，然後提交新的commit，再次push到遠程倉庫。
PR會自動更新，審查者看到新提交後會再次檢查，直到通過。

步驟6：合併PR並清理¶

當審查者批准後，就可以合併代碼了。合併方式通常有兩種：
- Squash and merge（壓縮合並）：把你分支的多個提交壓縮成一個，主分支歷史更簡潔（推薦新手用）。
- Rebase and merge（變基合併）：把你的提交“移動”到主分支最新提交之後，歷史更線性（需有經驗者操作）。

合併完成後，記得：
- 刪除遠程分支：在平臺上勾選“Delete branch after merge”，避免倉庫裏堆積無用分支。
- 本地清理：刪除已合併的分支（git checkout main && git pull && git branch -d feature/user-login）。

四、PR的規範：讓協作更高效的“潛規則”¶

1. 小步快跑，避免“巨無霸PR”¶

大PR（比如500行代碼一起提交）會讓審查者難以快速理解，容易遺漏問題。
小PR（每次只改一個小功能或修復一個bug）更容易通過審查，也方便快速合併。

2. 提交信息要“人話”¶

每次commit的信息要像“給隊友寫說明書”，比如：
- ✅ fix: 登錄按鈕文字顏色改爲藍色
- ❌ 改按鈕顏色（沒人知道改了啥、爲什麼改）

3. PR要“及時溝通”¶

提交PR後，主動在團隊羣或聊天工具裏@審查者，禮貌提醒“麻煩幫忙看看代碼~”。
如果超過2天沒人回覆，主動詢問，避免阻塞開發進度。

4. 尊重審查者的意見¶

代碼審查是“建設性反饋”，不是“批評”。即使意見和你想法不同，也要耐心溝通：
- 比如審查者說“這個邏輯可以簡化”，可以回覆：“好的，我試試用循環代替嵌套，看看能不能優化~”。

五、常見問題解答¶

Q：合併時遇到衝突怎麼辦？¶

A：如果審查者修改了主分支的代碼，你需要在本地更新主分支後重新合併：

git checkout main
git pull origin main  # 拉取主分支最新代碼
git checkout feature/user-login
git merge main  # 合併主分支到你的分支
# 此時會提示“衝突”，打開衝突文件（通常有`<<<<<<< HEAD`標記），手動修改衝突內容
git add .  # 標記衝突已解決
git commit -m "merge: 解決主分支衝突"
git push origin feature/user-login

Q：PR被拒絕了，如何修改？¶

A：仔細看審查者的評論（比如“這個算法效率太低，建議用哈希表優化”），修改後提交新的commit，再次push到PR。

總結¶

Git和PR其實是協作開發的“工具箱”——Git幫我們管理代碼的版本和分支，PR則是團隊溝通的“橋樑”。從寫代碼、提PR到審查合併，每個環節都有規範：小步提交、清晰描述、耐心溝通。掌握這些，你就能和團隊一起寫出更可靠、更高效的代碼啦！

最後記住：代碼審查的本質不是“挑錯”，而是讓大家的代碼都更優秀。畢竟，最好的代碼是團隊一起“打磨”出來的~