在使用 Git 和 GitHub 进行协作开发时，很多人会遇到这样的情况：你提交了一个拉取请求（Pull Request），之后又往源分支继续推送了新提交，这时候你会发现，这个拉取请求里的内容自动变了。这说明，拉取请求并不是一个静态快照，而是动态关联着你的分支。
拉取请求是动态的
当你创建一个拉取请求时，GitHub 实际上只是记录了“从哪个分支”向“目标分支”合并的意图。只要你的源分支有新的提交，这些更改会自动反映在对应的拉取请求中。不需要手动刷新或重新创建，系统会实时同步新增的代码变动。
比如，你基于 main 分支创建了 feature/login，并发起 PR。之后你发现登录逻辑有 bug，又提交了两处修复并推送到 feature/login，这时 PR 页面会立刻显示最新的三次提交，审查人员看到的就是更新后的完整变更。
自动同步的工作机制
这种同步依赖于分支名称的绑定关系。只要你不删除原分支，GitHub 就能持续追踪该分支的最新 commit hash，并将差异展示在 PR 的 “Files changed” 选项卡里。一旦有新 push，页面刷新后就能看到新增的修改行。
如果项目启用了 CI/CD 流水线，每次同步也会触发新一轮测试。例如，在 .github/workflows/test.yml 中配置的流程会随着每一次提交自动运行：
name: Run Tests
on: [pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm install
- run: npm test这意味着，哪怕是你为了修复 CI 失败而推送的一次小调整，也会被自动纳入当前 PR，并重新执行检查。
什么时候不会自动更新
有一种情况例外：如果你关闭了 PR 后又重新打开，它依然保留原来的分支关联，仍可继续同步。但如果你删掉了源分支，PR 就变成“无源之水”，无法再接收新提交。此时页面会提示 “This branch has been deleted.” 虽然历史记录还在，但不能再添加新改动。
另外，某些企业内部的 GitLab 或 Gitee 部署可能配置了不同的行为策略，例如限制 PR 更新频率或需要审批才能合并后续提交，这类属于自定义规则，并非默认机制。
如何避免意外更新
有时候你不希望后续提交影响已有 PR。比如你在同一个分支上同时开发两个功能，可以考虑拆分成独立分支。每个功能对应一个 PR，互不干扰。这样即使你继续开发下一个特性，也不会把无关代码带进正在评审的请求里。
举个例子：
# 正确做法：分离关注点
git checkout main
git checkout -b feature/button-style
# 修改按钮样式，提交并推送到远程
git push origin feature/button-style
# 创建 PR1
git checkout main
git checkout -b feature/input-validation
# 添加表单验证，提交并推送
git push origin feature/input-validation
# 创建 PR2这样一来，两个 PR 各自独立，各自同步，不会互相污染。