維護人員指南
本指南適用於維護人員。這些特殊人員擁有 Homebrew 儲存庫的寫入權限，並協助合併其他人的貢獻。您可能會發現這裡寫的內容很有趣，但這絕對不是初學者指南。
概觀
鼓勵所有 Homebrew 維護人員為專案的所有部分做出貢獻，但維護人員通常會加入四個主要團隊
brew維護人員：此團隊維護Homebrew/brew儲存庫。請參閱 Homebrew/brew 維護人員指南 以進一步瞭解成為brew維護人員的詳細資訊。- 核心維護人員：此團隊維護
Homebrew/homebrew-core儲存庫。請參閱 Homebrew/homebrew-core 維護人員指南 以進一步瞭解成為核心維護人員的詳細資訊。 - Linux 維護人員：此團隊在 Linux 上維護
Homebrew/homebrew-core儲存庫。 - Cask 維護人員：此團隊維護
Homebrew/homebrew-cask和Homebrew/homebrew-cask-fonts儲存庫。請參閱 Homebrew/homebrew-cask 維護人員指南 以進一步瞭解成為 cask 維護人員的詳細資訊。
這些文件旨在作為指導原則。作為維護人員，您可以根據貢獻者的舒適度和先前貢獻，要求他們變更或協助他們。請記住，作為一個團隊，我們 優先考慮維護人員而非使用者 以避免精疲力竭。如果您希望變更或討論任何指南：請開啟公關建議變更。
審查公關
在審查公關時，請根據以下指南在提交時使用「核准」、「核准並附註解」、「註解」或「要求變更」
- ✅ 核准：如果您認為公關看起來不錯，您可以 ✅ 原樣核准。
- ✅ 核准並附註解：如果您有幾個問題或註解需要回答，並且公關可以在處理後合併，您可以 ✅ 核准並附註解。
- 請相信其他維護人員不會在註解處理完畢之前合併公關，而不是例如讓他們再等 24 小時才能獲得另一份審查。
- 如果啟用自動合併：如果你想確保在至少已讀取你的留言前不會合併公關，你可以停用它（在 homebrew-core/cask 中加入
automerge-skip）。
- 🗣️ 留言：如果你需要在提供 ✅ 核准前提出問題，但對於其他人在你之前提供 ✅ 核准沒意見，請提供留言評論並提出問題。
- 🚫 要求變更：最後的手段。
- 在審查非維護者的公關時：這表示「在其他人合併此公關之前，必須進行這些變更」。在進行這些變更後，其他維護者可以取消此審查。
- 在審查其他維護者的公關時：這應盡量避免。
- 將其保留為「如果在我個人有機會 ✅ 核准之前合併此公關：它似乎很可能會造成使用者可見的問題」。
- 專案負責人可能會用它表示「此功能在 Homebrew 中不可接受」。在這種情況下：應暫停其他程式碼變更，直到同意此功能可以接受為止。
相關
- 預設選項應為 ✅ 核准，無論是否有留言。
- 只要有可能，你都應嘗試使用 GitHub「建議」功能來編輯程式碼，使其符合你的喜好。如果你沒有時間或不想費心：你可能沒有時間適當地審查公關。
- 我們是一個全球分佈的團隊，這有助於我們更快地行動。
- 公關審查流程主要是一種安全措施，而不是在合併前就完美程式碼風格達成共識的方法。
- 在核准後，很容易對公關進行變更，進行後續公關以處理留言或在標籤前還原公關。
- 在未經核准的情況下合併公關（幾乎）是不可能的。
- 使用
gh pr checkout <URL>是使用 GitHub CLI 檢出公關分支的超簡單方法。
任務
Homebrew 旨在成為 macOS（和 Linux）的遺失套件管理員。它的主要目標是對盡可能多的人有用，同時由一小群志工以專業、高標準的方式維護。在可能和合理的情況下，它應尋求使用 macOS 的功能，以融入 macOS 和 Apple 生態系統。在 Linux 和 Windows 上，它應盡可能獨立。
常見「陷阱」
- 確保已正確設定你的使用者名稱和電子郵件地址
- 如果您修改了 cherry-pick，請簽署 (使用
git -s) - 如果您的提交修復了錯誤，請使用 問題連結語法 (例如「修復 #104」) 來關閉錯誤報告並連結回提交
新增留言
僅參考問題單可能就足夠了，但請確保變更和背景夠清楚，讓第一次閱讀的人也能理解。您不希望自己編寫的程式碼被移除，因為有新人不懂它為什麼在那裡。回歸很糟糕。
這也適用於問題和 PR 主體。請盡可能明確。如果一個 pull request 是較大專案的一部分：請連結到相關的追蹤問題。如果還沒有追蹤問題：請建立一個以改善溝通並取得共識。
不要允許過大的 diff
修改 cherry-pick 以移除僅為空白變更的提交。它們不可接受，因為我們的歷史很重要，而且 git blame 應該是有用的。
允許空白更正 (例如符合 Ruby 標準等)（事實上這是個好時機），前提是該行本身有一些修改，而不仅仅是空白變更。但請小心對內嵌修補程式的變更，請確保它們仍然適用。
關閉問題/PR
維護人員 (包括專案負責人) 不應關閉其他維護人員開啟的問題或 pull request（請注意，合併在此情況下不視為關閉），除非它們已過時，在這種情況下，任何維護人員都可以關閉它們。鼓勵任何維護人員在希望對問題進行額外處理時重新開啟已關閉的問題。
任何維護人員都可以合併他們仔細檢閱且通過 CI 的任何 PR，這些 PR 是由任何其他維護人員開啟的。如果您不希望其他維護人員合併您的 PR：請使用草稿 pull request 狀態來表示，直到您準備好自己合併為止。
還原 PR
任何維護人員都可以針對其他維護人員建立的公關，在使用者提交問題或 CI 失敗後進行還原。建立原始公關的維護人員應獲得不少於一小時的時間，以自行修復問題或自行決定還原公關（如果他們願意）。
給予其他維護人員時間進行審查
公關是對現有功能的「增強」，即不是對公開使用者問題/討論的修復、不是版本升級、不是安全修復、不是對 CI 失敗的修復、可用性改善、新功能、重構等，應在星期一至星期五等待 24 小時後才能合併。例如，
- 星期四下午 5 點提交的新功能公關應等到星期五下午 5 點後才能合併
- 星期五下午 5 點提交的可用性修復公關應等到星期一下午 5 點後才能合併
- 使用者回報問題修復公關可以在 CI 為綠色後立即合併
如果維護人員在此期間休假/度假/生病，並在返回後留下評論：請將合併後公關的評論和回饋視為在時限內留下的，並以另一個公關進行後續追蹤以滿足其要求（如果同意）。
絕大多數的 Homebrew/homebrew-core 公關是錯誤修復或版本升級，可以在 CI 完成後自行合併。
溝通
維護人員有多種方式可以彼此溝通
- GitHub 上的 Homebrew 公開儲存庫
- Homebrew 在私人頻道（例如 GitHub/Slack）上兩個以上維護人員之間的群組通訊
- Homebrew 在私人頻道（例如 iMessage/Slack/傳書鴿）上兩個維護人員之間的直接 1:1 訊息
所有溝通理想上應在 GitHub 上公開進行。如果這不可行或不適當（例如安全揭露、兩個維護人員之間的人際問題、需要解決的緊急中斷），則可以轉移到維護人員的私人群組通訊，必要時進行 1:1 通訊。技術決策不應在 1:1 通訊中發生，但如果發生（或過去發生），則必須最終返回 GitHub 上可以連結的東西。例如，如果一年前在 Slack 上做出了技術決策，而另一位維護人員/貢獻者/使用者在 GitHub 上詢問此事，這是向他們解釋並提供未來可以連結的東西的好機會。
這讓其他維護人員、貢獻者和使用者更容易追蹤我們正在做的事情（更重要的是，為什麼我們這麼做），並表示決策有一個可連結的 URL。
所有維護人員（和專案負責人）透過任何媒體進行的溝通都受 Homebrew 行為準則 約束。對其他維護人員、貢獻者或使用者的辱罵行為將不被容忍；維護人員將會收到警告，如果他們的行為持續，他們將被移除維護人員身分。
維護人員應當自由地對其他維護人員的工作和決策提出善意的異議。維護人員之間健康、友善、技術性的異議是積極鼓勵的，並且應當在問題追蹤器上公開進行，以使專案變得更好。人際關係問題應當在 Slack 中私下處理，最好有主持人。如果工作或決策沒有得到充分的記錄或說明，任何維護人員或貢獻者都應當自由地要求澄清。沒有任何維護人員可以僅僅用「因為我這麼說」或「是我做了 X」來證明決策的合理性。在問題追蹤器上進行無關討論、自行車棚效應和人身攻擊是被禁止的。
