Pull Request（常縮寫為PR，中文常譯作“拉取請求”或“合併請求”）是一種在基於Git的代碼託管平台（如GitHub、GitLab等）中廣泛使用的代碼協作機制。其核心是開發者向項目倉庫提議代碼變更，並請求其他協作者進行審查。典型流程為：開發者創建分支並完成調整後，發起一個Pull Request，其中會清晰展示代碼差異（Diff）。項目維護者或其他團隊成員可在此請求內評論代碼、提出調整意見、進行討論與投票。經審查批准後，這些代碼變更才會被合併到目標分支（如主分支）。該機制是保障代碼質量、促進團隊知識共享和實現高效協作式開發的關鍵實踐。
基本介紹
- 中文名：拉取請求、合併請求
- 外文名：Pull Request
- 別名：PR
研發背景,發展歷程,運營模式,核心團隊,重要事件,
研發背景
Pull Request（拉取請求）是一種在兩個代碼倉庫間提交變更的協作機制，通常用於Fork倉庫向被Fork倉庫提交差異。例如，在開源貢獻中，貢獻者通常先Fork目標倉庫，在其副本上創建分支進行修改，然後通過Pull Request向原倉庫提議合併這些更改。在團隊內部，它也用於管控代碼合入許可權，例如規定開發者只能通過Pull Request而非直接推送的方式向主倉庫提交代碼，由具有相應許可權的維護者進行審查後合併。其核心目的是在合併代碼更改前，發起代碼審查和討論，以保障代碼質量和項目一致性。它不僅是代碼合併的請求，更是一種結構化的變更表達和協作工具，旨在通過透明的審查過程保障代碼質量、促進團隊知識共享、及時發現並修復潛在問題。
這裡用到的 pull 這個詞顯得非常生動，就像有一條繩子聯繫著原倉庫里的代碼和你 fork 來的代碼，你抓取了他人的代碼進行修改，並向原作者提出請求：我修改了你們的代碼，請你拉回去看看吧！
該機制源於開發者需要一種方式，在修改他人代碼後，請求原作者審查並採納修改。在典型的Git協作工作流中，開發者完成功能開發或問題修復後，通過創建Pull Request將遠程特性分支的更改提議合併到遠程主分支，這一過程也便於在合併前持續集成遠程更改，及時解決可能出現的合併衝突。它支持開源項目和團隊協作，是開發者參與項目貢獻、進行代碼審查和質量控制的主要方式之一。
Pull Request 的概念和實踐起源於代碼託管平台（如GitHub）為滿足分散式協作需求而發展的功能。作為GitHub等平台的基礎協作功能，Pull Request 允許開發者圍繞代碼變更進行討論和審查，而後才將其合併。GitHub平台在2008年推出時未集成Pull Request功能，早期貢獻者通過站內私信請求項目維護者合併代碼更改，不久之後，GitHub將Pull Request作為一個獨立的按鈕功能推出。在經歷約兩年、處理了20萬個PR後，GitHub於2010年左右推出了“Pull Request 2.0”，將其演變為一個包含代碼變更對比、圍繞代碼進行討論的完整協作式代碼審查流程。2011年，GitHub引入了“合併按鈕”，用戶無需再通過命令行操作，一鍵即可完成代碼合併並關閉PR。此後，GitHub及其他平台（如GitLab、Azure Repos等）陸續引入了草稿PR、強制性的代碼審查流程、與CI/CD工具的深度集成、合併佇列等特性。
2024年，文科生楊天潤通過自主搭建的多智慧型體系統向OpenClaw項目批量提交約134個Pull Request，其中21個被合併，通過率為15.7%。因向Agent下達“加快速度”指令導致行為失控，PR質量驟降、重複提交增多、評論區頻繁@維護者催審，觸發社區干預。GitHub隨後更新PR提交規則，設定每位作者最多同時保持10個開放狀態PR，超限自動標記r: too-many-prs並關閉。明確回應近期遭遇的“AI生成低質代碼(AI slop)”、同一修改重複提交及其他冗餘內容衝擊，指出此類行為嚴重消耗志願審核者時間。
發展歷程
Pull Request基於Git的request-pull子命令。其功能在GitHub等代碼託管平台上演進，提供包含代碼變更對比和討論的代碼審查與合併流程。
GitHub平台在2008年推出時未集成Pull Request功能，早期貢獻者通過站內私信請求項目維護者合併代碼更改。同年，GitHub推出了“提交評論”功能，允許用戶在特定代碼行下留言。
不久之後，GitHub將Pull Request作為一個獨立的按鈕功能推出。在經歷約兩年、處理了20萬個PR後，GitHub於2010年左右推出了“Pull Request 2.0”，將其演變為一個包含代碼變更對比、圍繞代碼進行討論的完整協作式代碼審查流程。
2011年，GitHub引入了“合併按鈕”，用戶無需再通過命令行操作，一鍵即可完成代碼合併並關閉PR。
此後，GitHub及其他平台（如GitLab、Azure Repos等）陸續引入了草稿PR、強制性的代碼審查流程、與CI/CD工具的深度集成、合併佇列等特性。
運營模式
Pull Request（PR）在現代軟體開發流程中扮演著核心角色，常作為代碼進入主幹分支的唯一強制通道。PR不僅是一個合併代碼的請求，更是一個代碼審查的平台。PR 的核心目標不僅是合併代碼，更是對變更進行結構化表達，需要清晰說明為什麼改、改了什麼以及如何驗證。
典型的“Fork + Pull Request”模式中，貢獻者首先Fork原倉庫，然後從自己的倉庫向原倉庫發起PR。具體操作步驟通常包括：貢獻者將目標倉庫復刻（Fork）到個人賬戶，在復刻倉庫中創建新分支進行開發，完成修改並提交後，在原始項目頁面發起“Compare & pull request”操作。此外，在企業或團隊內部協作中，更常採用“分支 + Pull Request”模式：開發者在同一倉庫內創建功能分支，開發完成後直接向受保護的主分支（如main或master）發起PR。Pull Request是兩個倉庫提交變更的一種方式，通常用於fork倉庫與被fork倉庫的差異提交。對倉庫具有讀取許可權的任何人都可以創建拉取請求，但要創建分支，必須具有寫入許可權。如果要為拉取請求創建新分支，又沒有倉庫的寫入許可權，可以先對倉庫復刻。拉取請求只能在不同的兩個分支之間打開，可以連結到議題（Issue），以便跟蹤修復進度並在合併時自動關閉議題。
PR可與CI/CD流程深度集成，例如在創建合併請求時自動觸發代碼質量掃描或自動化測試。審核結果作為評論添加到合併請求中。存在專門用於自動化創建合併請求的工具，例如基於GitLab API的工具，可通過命令行參數指定項目、分支等信息創建MR，並可集成到GitLab的CI/CD流程中實現自動化操作。2026年4月，Anthropic公司為其AI編程助手Claude Code推出“Routines”（例程）功能，支持通過GitHub事件（如新PR、新Issue、代碼推送）自動觸發AI代理執行任務，例如分析代碼、修復Bug或執行代碼審查，並創建Pull Request草稿等待人工審核。用戶可以為Routine設定過濾條件，如限定目標分支、標籤或代碼模組，以實現更精準的自動化回響。AI代理以用戶身份執行操作並創建PR，相關責任由用戶承擔。
企業或項目可設定代碼審查規則，如指定默認審核人員、設定必須的審閱者人數或批准條件。付費企業用戶默認開啟代碼缺陷掃描，會自動掃描任何提交過來的Pull Request中的缺陷和規範問題。在審查流程中，通常涉及提交者（Author）和審查者（Reviewer）等角色。提交者需要主動解釋複雜邏輯並及時回響審查意見；審查者則聚焦於代碼問題本身，區分必須修改和建議最佳化的點。基於安全考慮，許多項目設定為只能通過PR的方式將代碼合入主倉庫，而不能直接推送（push），由具有合併許可權的Committer進行最終審核。一個完整的PR通常包含多個功能標籤頁：Conversation（對話）頁顯示變更描述、時間線和評論；Commits（提交）頁按時間順序展示所有相關提交；Checks（檢查）頁顯示自動化測試、構建等持續集成工作流的狀態；Files changed（更改的檔案）頁則清晰展示提議的更改與現有代碼的差異。此外，還可以創建草稿PR（Draft Pull Request）來分享進行中的工作，而無需正式請求評審。
不同代碼託管平台對PR的運營有特定限制，例如Gitee平台限制PR的源倉庫與目標倉庫需存在fork與被fork關係。此外，不同平台對類似功能的命名略有不同：GitHub稱為Pull Request (PR)，GitLab稱為Merge Request (MR)，Bitbucket也稱為Pull Request。
PR流程可以集成到第三方協作工具中，例如可以將GitHub的議題（Issue）或PR引入Microsoft Loop進行協作討論，但在Loop中導入的GitHub表本質上是靜態的，對表內詳細信息的更改可以雙向同步。
核心團隊
Pull Request流程主要涉及三方核心角色：發起者（貢獻者）、審查者、合併者（通常為項目維護者或擁有許可權者）。發起者負責創建PR，描述更改。發起者可以創建草稿拉取請求以分享進行中的工作，待準備就緒後再標記為可供審查。審查者負責評審代碼，提出問題和建議，並投票決定是否批准。合併者擁有最終合併許可權，在審查通過且滿足分支策略後執行合併操作。PR不僅是一個合併代碼的請求，更是一個代碼審查（Code Review）的平台。團隊其他成員可以在PR中對代碼進行評論、提出建議。這種機制是保障主幹代碼質量、促進知識共享的關鍵流程。平台功能（如@提及）支持團隊成員間的溝通。
重要事件
2024年，文科生楊天潤通過自主搭建的多智慧型體系統向OpenClaw項目批量提交約134個Pull Request，其中21個被合併，通過率為15.7%。因向Agent下達“加快速度”指令導致行為失控，PR質量驟降、重複提交增多、評論區頻繁@維護者催審，觸發社區干預。OpenClaw管理員刪除低質PR並發出封禁警告，最終所有未合併PR被批量關閉。
GitHub隨後更新PR提交規則，設定每位作者最多同時保持10個開放狀態PR，超限自動標記r: too-many-prs並關閉。明確回應近期遭遇的“AI生成低質代碼(AI slop)”、同一修改重複提交及其他冗餘內容衝擊，指出此類行為嚴重消耗志願審核者時間。
2026年4月16日，AI公司Anthropic官宣Claude Code的“Routines”功能進入研究預覽版。該功能的核心之一是能夠回響GitHub事件（如Pull Request創建、issue提交、代碼推送），自動執行代碼任務並創建或管理Pull Request，實現了AI Agent自動化編程工作流的產品化。
在成熟的開源生態中，Pull Request（PR）與Issue一同被視為項目工程質量與社區協作效率的核心載體，一個規範的PR能顯著降低維護成本、提升合併效率。規範的PR被視為“變更的結構化表達”，需明確說明修改背景、內容和驗證方式。社區倡導小步提交、關注可讀性、自包含等質量標準，並利用CI/CD自動化工具和PR模板來提升審查效率與代碼質量。
此外，主流編程測評基準常使用原始PR評論作為評估真值，以測試AI模型處理實際開發任務和長期代碼維護的能力。
