編譯自： https://julien.danjou.info/stop-merging-your-pull-request-manually/
如果有什麼我討厭的東西，那就是當我知道我可以自動化它們時，但我手動進行了操作。只有我有這種情況麼？我覺得不是。
儘管如此，他們每天都有數千名使用 GitHub 的開發人員一遍又一遍地做同樣的事情：他們點擊這個按鈕：
Screen-Shot-2018-06-19-at-18.12.39
這沒有任何意義。
不要誤解我的意思。合併拉取請求是有意義的。只是每次點擊這個該死的按鈕是沒有意義的。
這樣做沒有意義因為世界上的每個開發團隊在合併拉取請求之前都有一個已知的先決條件列表。這些要求幾乎總是相同的，而且這些要求也是如此：
- 是否通過測試？
- 文檔是否更新了？
- 這是否遵循我們的代碼風格指南？
- 是否有若干位開發人員對此進行審查？
隨著此列表變長，合併過程變得更容易出錯。 “糟糕，在沒有足夠的開發人員審查補丁時 John 就點了合併按鈕。” 要發出警報麼？
在我的團隊中，我們就像外面的每一支隊伍。我們知道我們將一些代碼合併到我們倉庫的標準是什麼。這就是為什麼我們建立一個持續集成系統，每次有人創建一個拉取請求時運行我們的測試。我們還要求代碼在獲得批准之前由團隊的 2 名成員進行審查。
當這些條件全部設定好時，我希望代碼被合併。
而不用點擊一個按鈕。
這正是啟動 Mergify 的原因。
github-branching-1
Mergify 是一個為你按下合併按鈕的服務。你可以在倉庫的 .mergify.yml 中定義規則，當規則滿足時，Mergify 將合併該請求。
無需按任何按鈕。
隨機抽取一個請求，就像這樣：
Screen-Shot-2018-06-20-at-17.12.11
這來自一個小型項目，沒有很多持續集成服務，只有 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中國 榮譽推出
閱讀更多 Linux中國 的文章
