如果有什麼我討厭的東西，那就是當我知道我可以自動化它們時，但我手動進行了操作。只有我有這種情況麼？我覺得不是。
儘管如此，他們每天都有數千名使用 GitHub 的開發人員一遍又一遍地做同樣的事情：他們點選這個按鈕：
這沒有任何意義。
不要誤解我的意思。合併拉取請求是有意義的。只是每次點選這個該死的按鈕是沒有意義的。
這樣做沒有意義因為世界上的每個開發團隊在合併拉取請求之前都有一個已知的先決條件列表。這些要求幾乎總是相同的，而且這些要求也是如此：
- 是否透過測試？
- 文件是否更新了？
- 這是否遵循我們的程式碼風格指南？
- 是否有若干位開發人員對此進行審查？
隨著此列表變長，合併過程變得更容易出錯。 “糟糕，在沒有足夠的開發人員審查補丁時 John 就點了合併按鈕。” 要發出警報麼？
在我的團隊中，我們就像外面的每一支隊伍。我們知道我們將一些程式碼合併到我們倉庫的標準是什麼。這就是為什麼我們建立一個持續整合系統，每次有人建立一個拉取請求時執行我們的測試。我們還要求程式碼在獲得批准之前由團隊的 2 名成員進行審查。
當這些條件全部設定好時，我希望程式碼被合併。
而不用點選一個按鈕。
這正是啟動 Mergify 的原因。
Mergify 是一個為你按下合併按鈕的服務。你可以在倉庫的 .mergify.yml 中定義規則，當規則滿足時，Mergify 將合併該請求。
無需按任何按鈕。
隨機抽取一個請求，就像這樣：
這來自一個小型專案，沒有很多持續整合服務，只有 Travis。在這個拉取請求中，一切都是綠色的：其中一個所有者審查了程式碼，並且測試透過。因此，該程式碼應該被合併：但是它還在那裡掛起這，等待某人有一天按下合併按鈕。
使用 Mergify 後，你只需將 .mergify.yml 放在倉庫的根目錄即可：
rules:
default:
protection:
required_status_checks:
contexts:
- continuous-integration/travis-ci
required_pull_request_reviews:
required_approving_review_count: 1
透過這樣的配置，Mergify 可以實現所需的限制，即 Travis 透過，並且至少有一個專案成員審閱了程式碼。只要這些條件是肯定的，拉取請求就會自動合併。
我們將 Mergify 構建為 一個對開源專案免費的服務。提供服務的引擎也是開源的。
現在去嘗試它，不要讓這些拉取請求再掛起哪怕一秒鐘。合併它們！
如果你有任何問題，請隨時在下面向我們提問或寫下評論！並且敬請期待 - 因為 Mergify 還提供了其他一些我迫不及待想要介紹的功能！
via: https://julien.danjou.info/stop-merging-your-pull-request-manually/
作者：Julien Danjou 選題：lujun9972 譯者：geekpi 校對：wxy
本文由 LCTT 原創編譯，Linux中國 榮譽推出
