科技爱好者周刊（第 412 期）：禁止 issue，只用 PR

引言

在传统的软件开发协作中，Issue（问题/任务）往往是工作的起点。开发者领取一个 Issue，然后独立编码，最后提交代码。这种模式看似清晰，却隐含了诸多痛点：代码审查滞后、知识传递不畅、集成测试延迟，甚至导致“孤岛式”开发。

近年来，一种更为强调协作与透明度的工作流逐渐受到推崇：“禁止 Issue，只用 PR”。这并非字面意义上完全消灭 Issue 跟踪工具，而是指将工作的核心载体和协作焦点，从孤立的 Issue 转变为围绕 Pull Request（PR，拉取请求）展开。所有功能开发、缺陷修复、文档更新，都通过创建 PR 来发起、讨论和完成。本文将深入剖析这一模式的原理、实践与注意事项。

原理要点

“只用 PR”模式的核心思想，是将代码变更的提出、审查、讨论和合并过程，作为团队协作的唯一中心枢纽。其优势根植于以下几个关键原理：

1. 强制代码审查与知识共享：每个 PR 都必须经过至少一位同事的审查才能合并。这确保了代码质量，同时让团队成员了解彼此的工作，减少知识壁垒。
2. 自动化集成与验证：PR 的创建、更新和合并可以自动触发 CI/CD（持续集成/持续部署）流水线。这意味着每次变更都会经过自动化测试、构建和检查，确保集成健康。
3. 上下文丰富的讨论：讨论直接附着在具体的代码变更上，而非一个抽象的 Issue 描述中。审查者可以针对某一行代码提出意见，作者可以即时回复和修改，沟通效率更高。
4. 可追溯的变更历史：PR 本身就是一个完整的变更记录，包含了谁在何时提出了什么修改、讨论了什么、最终如何合并。这为项目审计和问题回溯提供了宝贵信息。

实战步骤

推行“只用 PR”工作流，需要一套清晰、通用的操作流程。以下是一个典型的生命周期：

步骤一：从 Issue 到 PR 的转换

即使不“禁止”Issue 跟踪，也应将其视为 PR 的前置描述，而非工作载体。

1. 在 Issue 跟踪工具中创建一个 Issue，描述需求或问题。
2. 开发者基于该 Issue 创建功能分支。
3. 当开发完成，准备合并时，创建 PR。在 PR 的描述中，引用对应的 Issue 编号（如 Closes #123），将 Issue 作为 PR 的上下文补充。

步骤二：创建与提交 PR

1. 在代码仓库中，从你的功能分支向目标分支（如 main 或 develop）发起 PR。
2. 填写清晰的 PR 标题和描述。描述应说明变更的目的、主要修改点以及测试情况。
3. 提交 PR 后，CI 流水线自动启动。

# 通用示例：创建功能分支并推送
git checkout -b feature/add-new-module
# ... 进行开发 ...
git add .
git commit -m "feat: implement new module"
git push origin feature/add-new-module
# 然后在代码托管平台（如 your-org/repo）的 Web 界面创建 PR

步骤三：审查与讨论

1. 审查者收到 PR 通知，在平台界面上查看代码变更。
2. 审查者可以提出评论、建议或批准。评论可以针对整个 PR，也可以针对特定代码行。
3. 作者根据反馈修改代码，并推送到同一功能分支。PR 会自动更新，显示新的变更和 CI 结果。

步骤四：合并与清理

1. 当所有审查意见被处理，CI 流水线全部通过，且审查者批准后，即可合并 PR。
2. 合并后，可以选择删除已合并的功能分支，保持仓库整洁。

# 通用示例：合并后清理本地分支
git checkout main
git pull origin main
git branch -d feature/add-new-module

常见坑与排查清单

推行新工作流时，团队可能会遇到以下常见问题：

小结

“禁止 Issue，只用 PR”本质上是一种以代码变更为中心的协作哲学。它通过强制审查、自动化验证和上下文化讨论，将代码质量保障和知识共享嵌入到日常开发流程中。虽然推行初期需要团队适应和习惯养成，但长期来看，它能显著提升代码的可维护性、团队的协作效率以及项目的整体健康度。关键在于找到适合自身团队节奏的实践方式，并持续优化。