登录失败时清空密码
feature/login-error→main
- Checks · 运行中
- Reviewers · 0
Merge 禁用
门禁未齐
分支已请求合入 main。CI 还没出结果，合并按钮是灰的。
先认出这张 PR 页，再看 Merge 为什么是灰的
下面就是平台上的 Pull Request。默认检查还在跑；CI 失败会把红灯写在检查行上；绿灯加批准后，按钮才变成已合入。
第 0 步先打开：git push origin feature 后，在 GitHub / GitLab 点 New Pull Request。下面就是那张 PR 页。
原因：PR 已开，CI 还在跑。下一步：等检查，或先看失败会怎样挡住合并。
知识点：请求合入，不是直接灌 main
PR 页刚走过的路，这里只给命名。
- PR 列出 commit、diff，并挂上 CI 与评审门禁。
- 合并 = CI 通过 且 至少 1 人批准。
- request-changes 阻断；comment 不算批准；pending 也禁用合并。
- 合并后保留检查和评审快照，便于回溯。
什么时候用、怎么用
改动要进共享分支，就走 PR。
- 信号：feature 写完，想合进 main，而不是自己 push 覆盖。
- 最短路径：push 分支 → 开 PR（标题写用户结果）→ 等 CI → 请人审 → 绿且批准再合。
- 不适用：直接 push 共享 main、CI 红了还强行合、用 comment 冒充批准。
正反例：同一个 feature，只改一处门禁
只改变「有没有走齐检查和批准」，可追溯性完全不同。
PR 页留下测试、评审和合并提交。出问题能回到这一页看谁批的、哪次检查绿的。
没有检查快照，也没有人签字。回滚只能猜哪次提交，责任对不上人。
快速自测
PR 已有 1 人批准，但 CI 还在 pending。这时 Merge 应是什么状态？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。