AI Skills
create-pr

create-pr

熱門

在 warp 儲存庫中為目前分支建立拉取請求。當使用者提到開啟 PR、建立拉取請求、提交變更以供審查或準備合併程式碼時使用。

124星標
0分支
更新於 2026/7/10
獲取技能源代碼

相關技能

gstack12萬observability-and-instrumentation7.9萬browser-automation4.3萬
SKILL.md
readonlyread-only
name
create-pr
description

Create a pull request in the warp repository for the current branch. Use when the user mentions opening a PR, creating a pull request, submitting changes for review, or preparing code for merge.

create-pr

概述

本指南涵蓋在 warp 儲存庫中建立拉取請求的最佳實務，包括合併 master、執行 presubmit 檢查、連結 Linear 任務、確保適當的測試覆蓋率，以及組織 PR 以利有效審查。

相關技能

  • fix-errors - 在開啟 PR 前修正 presubmit 失敗（格式化、lint、測試）
  • warp-integration-test - 為使用者可見流程、回歸問題及 P0 使用案例新增或更新整合測試覆蓋
  • add-feature-flag - 將變更隱藏在功能開關後

PR 前置檢查清單

1. 將 master 合併到你的功能分支

在開始審查流程前，務必將 master 合併到你的功能分支。

git fetch origin
git merge origin/master

在開啟 PR 前，先在本地解決所有合併衝突。

2. 對程式碼變更執行 presubmit 檢查

如果 PR 包含程式碼變更，請在開啟或更新 PR 前執行相關的 presubmit 檢查：

./script/presubmit

./script/presubmit 會執行：

  • cargo fmt - 程式碼格式化
  • cargo clippy - 將所有警告視為錯誤的 lint 檢查
  • 所有測試（單元測試、文件測試和整合測試）
    如果 PR 僅包含文件變更（例如技能、markdown 或其他非程式碼內容），則無需為了開啟或更新 PR 而執行 cargo fmt 或 cargo clippy。

如果 presubmit 在包含程式碼變更的 PR 上失敗，請使用 fix-errors 技能來解決問題。

在以下情況前，你必須執行 cargo fmt 和 cargo clippy：

  • 開啟一個包含程式碼變更的新 PR
  • 推送包含程式碼變更的新提交到現有 PR 分支
  • 任何經過審查且變更了程式碼的分支更新

3. 審查你的變更

在建立 PR 之前，請審查你即將提交的變更：

# 檢視分支中的提交（與基礎分支比較）
git --no-pager log <base-branch>..HEAD --oneline

# 檢視變更的檔案統計
git --no-pager diff <base-branch>...HEAD --stat

# 檢視完整 diff
git --no-pager diff <base-branch>...HEAD

這有助於你：

  • 確認所有預期的變更都已包含
  • 在審查前捕捉非預期的變更
  • 撰寫準確的 PR 描述
  • 確保你正在與正確的基礎分支進行比較
  • 測試： 在必要時包含測試——錯誤修復（回歸測試）、演算法程式碼（單元測試）、UI 元件（佈局測試）、P0 使用案例（整合測試）。請參閱下方的測試要求。

4. 連結到 Linear 任務

在可能的情況下，PR 應與 Linear 任務關聯。使用 Linear MCP 工具（如果可用）來尋找對應的問題。

分支命名慣例：
遠端分支應以你的名字為前綴（例如 zheng/feature、alice/fix-bug）。

如何將 PR 連結到 Linear：
在 PR 標題中包含問題 ID（例如 [WARP-1234] Add new feature）。請在建立 PR 之前執行此操作以實現自動連結。

5. 開啟 PR

開啟 PR 時，請使用位於 .github/pull_request_template.md 的 PR 模板。

在適當時，使用 PR 模板底部的格式新增變更日誌條目。一些範例：

  • 功能：「在目前目錄中跨檔案進行全域搜尋。使用 CMD-F/CTRL-SHIFT-F 開啟。」
  • 改進：「在跳轉到行/列時新增水平自動滾動。」
  • 錯誤修復：「修正當代理程式執行指令時，工作階段檢視器輸入被清除的問題。」

CLI 工作流程：

  • 檢查目前分支是否已有 PR：

    gh pr view --json number,url

    如果 PR 存在則回傳結束碼 0，否則回傳 1。

  • 建立新 PR：

    # 包含標題和內文
gh pr create --title "Title" --body "Description" --draft

# 從提交自動填入
gh pr create --fill --draft

# 使用 PR 模板檔案
gh pr create --body-file .github/pull_request_template.md --title "Title" --draft

    主要旗標：--draft / -d、--fill / -f、--body-file / -F、--web / -w

  • 更新現有 PR：

    gh pr edit --title "New title" --body "New body"
gh pr edit --add-reviewer username --add-label bug

  • 將 PR 標記為準備審查：

    gh pr ready

6. 包含共同作者歸屬

在提交變更或建立 PR 時，請在每個提交訊息或 PR 描述的末尾包含歸屬：

Co-Authored-By: Warp <agent@warp.dev>

測試要求

錯誤修復需要回歸測試

所有錯誤修復都應附帶回歸測試。 這有助於防止已經被破壞過的功能再次被破壞。

測試應：

  • 重現原始錯誤（在修復前會失敗）
  • 在套用修復後通過
  • 命名清晰，以表明它正在防止什麼錯誤

演算法程式碼需要單元測試

具有非平凡邏輯的程式碼應有單元測試來驗證功能：

需要單元測試的範例：

  • 自訂資料結構（例如 SumTree）
  • 應針對給定查詢回傳預期結果的搜尋相關 API
  • UI 框架中的核心佈局程式碼
  • 任何演算法或計算邏輯

不需要的情況：

  • 足夠簡單的函式
  • 平凡的 getter/setter

請遵循儲存庫的本地測試慣例來撰寫單元測試。

UI 元件需要佈局驗證測試

所有 UI 元件（View 的實作）都應有一個簡單的單元測試來驗證它們可以在不發生 panic 的情況下進行佈局。

這提供了渲染「安全性」（而非「正確性」）的高層級覆蓋：

#[test]
fn test_component_can_layout() {
    use warpui::App;
    use warp::test_util::{terminal::initialize_app_for_terminal_view, add_window_with_terminal};
    
    App::test((), |mut app| async move {
        initialize_app_for_terminal_view(&mut app);
        let term = add_window_with_terminal(&mut app, None);
        
        // 渲染元件 - 不應 panic
        term.update(&mut app, |view, ctx| {
            // 建立並佈局你的元件
        });
    })
}

跳過整合測試覆蓋前先詢問

如果 PR 變更了使用者可見流程、修正了端到端回歸問題，或者看起來會受益於整合測試覆蓋，請在建立或更新 PR 前使用 ask_user_question 工具詢問使用者是否希望將整合測試新增為工作的一部分。

偏好直接選擇，例如：

  • Yes, add an integration test before creating the PR
  • No, continue without an integration test

如果使用者選擇新增，請使用 warp-integration-test 技能。

P0 使用案例需要整合測試

所有「P0 使用案例」都需要一個整合測試來涵蓋相關的行為/流程。

「P0 使用案例」定義為： 任何應用程式的行為，如果被破壞，就需要進行帶外釋出。

整合測試應：

  • 執行完整的使用者面向流程
  • 驗證端到端功能
  • 放置在 integration/ 目錄中

有關實作細節、測試註冊步驟和驗證工作流程，請使用 warp-integration-test 技能。

PR 描述指南

你的 PR 摘要應在「Description」部分包含：

  1. What - 正在進行哪些變更
  2. Why - 為什麼需要這些變更（如果適用，請連結到 Linear 任務）
  3. How - 所採取方法的簡要說明

開啟 PR 後

  1. 監控 CI 檢查 - 確保所有自動化檢查通過
  2. 回覆審查意見 - 及時處理回饋
  3. 保持 PR 最新 - 如果發生衝突，合併 master
  4. 重新執行相關驗證 - 在根據審查回饋進行變更後。對於程式碼變更，重新執行 cargo fmt/cargo clippy（以及其他相關檢查）；對於僅文件變更，則不需要。

最佳實務

  • 保持 PR 聚焦 - 盡可能每個 PR 只做一個邏輯變更
  • 撰寫清晰的提交訊息 - 解釋做了什麼和為什麼，而不只是做了什麼
  • 先自我審查 - 在請求審查前先審查自己的 diff
  • 更新測試 - 確保測試覆蓋反映你的變更
  • 記錄破壞性變更 - 指出任何 API 變更或破壞性修改
  • 使用功能開關 - 在適當時將有風險的變更隱藏在功能開關後（請參閱 add-feature-flag 技能）