ELI5 · GitHub

九個字,其實只有三個

close closes closed fix fixes fixed resolve resolves resolved

先看它在做什麼

在 PR 的描述裡寫一行 Fixes #1, 就等於幫 GitHub 綁了一條線:這個 PR 一被合併,#1 那張單子自己就關了。

你做的事
✍️
Fixes #1
寫在 PR 的描述欄裡
誰按的
🤝
Merge
PR 被合併進 main 的那一刻
自動發生
🎉
#1 Closed
不用你手動去關,兩邊還互相留連結

九個字 = 三個動詞 × 三種變化

這九個字不是九件不同的事。是三個英文動詞,每個各有三種長相。

原形
(像在下指令)
加 s
(在描述這個 PR)
加 ed
(說已經做完了)
關門
close
close關掉它
closes這 PR 會關掉它
closed已經關掉了
修東西
fix
fix修掉它
fixes這 PR 會修掉它
fixed已經修好了
解決問題
resolve
resolve解決它
resolves這 PR 會解決它
resolved已經解決了

← 左右滑動可以看完整張表 →

大小寫 GitHub 完全不看。FIXES #1Fixes #1fixes #1 一模一樣。

三個動詞,英文的語氣不一樣

差別只在別人讀你的 PR 時,心裡浮出什麼畫面

🚪
close
關上、結案
「這件事到這裡結束了。」
最中性的一個。它沒有說東西壞了,也沒有說你修好了什麼——只說「這張單子可以收起來了」。
適合:新增一個功能、單子過期了、決定不做了、只是清掉待辦。
🔧
fix
修好、修掉
「它本來壞了,我修好了。」
用了這個字,你就是在說那張單子是一個 bug。讀的人會預期你的改動是在修正錯誤,不是加新東西。
適合:程式出錯、行為不對、打錯字、壞掉的測試。
resolve
解決、有了結論
「本來是個懸著的問題,現在有答案了。」
比 fix 大一圈。它不一定是壞掉,可能是一個問題、一個需求、一場沒結論的討論,而你把它處理完了。
適合:需求單、技術選擇、效能問題、「要怎麼做」的討論。

那三種變化呢?

只是英文文法。GitHub 三種都認,行為零差別。

fix #1
原形
讀起來像在下指令:「去把 #1 修掉。」
最短,打字最快。
fixes #1
第三人稱單數
主詞是「這個 PR」:「這個 PR 修掉 #1。」
語意最自然,最多人用的就是這個
fixed #1
過去式
「我已經把 #1 修好了。」
寫在事後回顧的口吻裡比較順。

最重要的一件事

close · closes · closed
fix · fixes · fixed
resolve · resolves · resolved
▼ ▼ ▼
九個字做的事,一模一樣

GitHub 不管你挑哪一個:一樣綁定連結,一樣在合併時把 issue 關掉。 選字只影響讀起來的感覺,不影響機器的行為。 所以不用背九個——挑一個順口的(大家最常用 Fixes)一直用就好。

四個會讓它失效的地雷

寫在 PR 的標題
寫在 PR 的描述

關鍵字只在 PR 的描述欄(下面那塊大的)才生效。 放在標題那一行,GitHub 當普通文字,issue 不會關。

Fixes #1, #2
Fixes #1, fixes #2

關鍵字只管緊跟在它後面的那一個號碼。 兩張單子就得寫兩次關鍵字,不然第二張只會被留言連結、不會關。

合併到某個功能分支
合併到預設分支(main)

只有合併進 repo 的預設分支才會關 issue。 合併到別的分支,連結會在,但單子還是開著的。

Fixed the bug in #1
Fixes #1

關鍵字和 #號碼 之間不能夾別的字。 中間插了東西就只是一句話,不是綁定指令。

如果你不想讓它關掉呢

一件大事要好幾個 PR 才做完的時候,中途的 PR 不該把單子關掉。 那就避開那九個字——換成不在清單裡的說法。

Part of #1 「這是 #1 的一部分」——只留連結,不會關。
Related to #1 「跟 #1 有關」——只留連結,不會關。
See #1 「見 #1」——只留連結,不會關。
#1 光寫號碼也會連結,同樣不會關。

然後在最後那個收尾的 PR 才寫 Fixes #1,讓單子在事情真正做完時才關。

補一個小技巧:要關別的 repo 的單子,寫成 Fixes owner/repo#123 就行, 前面加上「誰的/哪個 repo」。

想再深入一點