Git for QA — Branch / PR review / cherry-pick / bisect 抓 regression 的實戰

「Git 是 dev 的事」是 5 年前的觀念。現在 QA 不會 Git 等於少一半戰力 — 看不懂 PR、找不到 regression commit、救不回手滑的測試。這篇是給 QA 的實戰 Git 指南。

不會 Git 的 QA = 每件事都要等 dev 處理。

核心：每次想做事前先問「我在哪個區域、要去哪個」。

看狀態

git status                    # 我現在在哪、什麼變了
git log --oneline -10         # 最近 10 個 commit
git log --graph --oneline     # 視覺化 branch
git diff                      # 我改了什麼還沒 add
git diff --staged             # 我 add 了什麼還沒 commit
git diff main                 # 跟 main 差什麼

切 branch

git branch                    # 列所有 branch
git branch -a                 # 含 remote
git checkout -b feature/x     # 建 + 切到新 branch
git checkout main             # 切回 main
git switch main               # 新版指令（同 checkout）

寫 code

git add tests/test_login.py   # stage 單檔
git add tests/                # stage 整個資料夾
git commit -m "test: add login flaky check"
git push origin feature/x     # 推到 remote

Pull 別人的 code

git fetch                     # 抓 remote 更新（不 merge）
git pull origin main          # fetch + merge
git pull --rebase             # 用 rebase 取代 merge

救手滑

git restore tests/login.py    # 丟掉某檔的修改
git restore --staged file     # 把 staged 還原回 working
git reset HEAD~1              # 取消最後 1 個 commit（保留改動）
git reset --hard HEAD~1       # 取消 + 丟掉改動（危險）

招式 1: git log 進階 — 找 regression commit

# 找誰改了 login.py
git log --follow tests/login.py

# 找這禮拜的改動
git log --since="1 week ago" --oneline

# 找 Alice 改的 E2E test
git log --author=alice -- tests/e2e/

# 找改了「login」字串的 commit
git log -S "login" --oneline

# 找改了 LoginPage class 的 commit
git log -G "class LoginPage" --oneline

# 看某 commit 改了什麼
git show abc1234

# 看某 commit 改了哪些檔案
git show --stat abc1234

招式 2: git diff — 對比兩個版本

# 對比 main 跟 staging branch
git diff main..staging

# 對比這個 PR 改了什麼
git diff main...feature/login

# 看哪些檔案改了
git diff --name-only main..staging

# 對比兩個 commit
git diff abc1234..def5678

# 對比兩個 tag
git diff v2.4.0..v2.4.1

QA 發版前一定要看 git diff lastrelease..main 確認 scope。

招式 3: git bisect — 二分查 regression（神技）

實際操作：

# 1. 知道現在壞、上版好
git bisect start
git bisect bad HEAD
git bisect good v2.4.0

# 2. Git 自動切到中間 commit
#    這時跑你的測試
npm run test:e2e:login

# 3. 結果回報
git bisect bad   # 如果還壞
# 或
git bisect good  # 如果好

# 4. 重複 2-3 直到找到
# 最後 Git 會說「abc1234 is the first bad commit」

# 5. 結束
git bisect reset

10 個 commit 之中找出壞的、只要測 log2(10) ≈ 4 次。

招式 4: git cherry-pick — Hotfix 走小路

某個 bug 修在 main、要 backport 回 release branch：

# 在 main 上的修復 commit
git log main --oneline
# abc1234 fix: payment race condition

# 切到 release branch
git checkout release/v2.4

# 把那個 commit 「挑」過來
git cherry-pick abc1234

# push 出去
git push origin release/v2.4

Cherry-pick 是 hotfix 工作流的核心。

看 diff 的順序

1. 整體 file 數：改 50 個檔案的 PR = 要拆
2. 新檔案 vs 修改檔案：新功能 vs 改舊行為
3. Test 檔有沒有跟著改：沒有 = 退回
4. API / schema 改動：標 breaking change
5. dependency / config：注意 security 與部署影響

Comment 的好習慣

不要只說「LGTM」。

✅ 好的 comment:
「這個 case 沒測 timeout 情境，我來補一個」
「這 schema 改動會 break v1 client，需要 deprecation period」
「flaky test 可能來自這個 race condition」

❌ 沒幫助的 comment:
「LGTM」
「+1」
「ok」

# 看你最近做過的所有「動作」
git reflog

# 輸出像這樣：
# abc1234 HEAD@{0}: reset: moving to HEAD~1
# def5678 HEAD@{1}: commit: my important test
# ...

# 救回 commit
git reset --hard def5678

90% 的「Code 不見」都能用 reflog 救。

QA 要會分辨：

• Bug 在 feature branch → 該 PR 退回 dev 修
• Bug 在 staging → 開 fix PR、merge 回 staging + cherry-pick main
• Bug 在 prod → 開 hotfix branch、修完同時 cherry-pick 給 staging / main

QA 要做的事不同：

1. git stash — 半途切走

# 改一半要切去看別的 branch
git stash                # 暫存
git checkout other       # 切走
# 看完...
git checkout original    # 切回
git stash pop            # 拿回剛剛改的

2. git revert — 安全的撤銷

# 不要用 reset、改用 revert（不改 history）
git revert abc1234       # 產生一個「撤銷 abc1234」的新 commit
git push                 # 安全推上去

已推到 remote 的 commit 一律用 revert、不用 reset。

3. git blame — 看每行誰寫的

git blame tests/login.py

每行顯示：commit、作者、時間。找到 regression 後找誰一起 debug。

1. Force push 到共享 branch

# ❌ NEVER
git push --force origin main

# ✅ 用 --force-with-lease（被別人 push 後會擋住）
git push --force-with-lease origin feature/x

2. Rebase 已 push 的 branch

已 push 的 commit 不要 rebase。會把別人的 history 搞壞。

3. Conflict 不知道怎麼解

<<<<<<< HEAD
我的版本
=======
別人的版本
>>>>>>> branch-x

步驟：

1. 看 <<< 跟 >>> 之間是兩邊版本
2. 決定留哪個、或合併
3. 刪掉 <<< === >>> marker
4. git add 該檔
5. git rebase --continue 或 git merge --continue

type(scope): one-line summary

[optional body]

[optional footer]

常用 type：

• feat: 新功能
• fix: bug 修復
• test: 加 / 改測試（QA 最常用）
• docs: 文件
• refactor: 重構
• chore: 雜事

QA 範例：

test(login): add flaky-check for connect timeout

Repro 3 次 100% fail，加 30s timeout retry guard。
Related: #1042

1. Git 不會 = 永遠等 dev
2. bisect 救你 80% 的 regression debug 時間
3. 手滑都能 reflog 救、別 panic
4. conflict 不可怕、看 marker 就好
5. 每天用 5 個指令、3 個月就熟

Git 是 QA 最被低估的技能。不會 → 每件事卡 dev；會了 → 你能自己找 regression、Review PR 講重點、救手滑。每天花 10 分鐘練、一個月後你會發現 Git 變成你的第二語言。