在开源协作或团队开发中，Pull Request（PR）是代码合并的核心机制。很多开发者在操作时容易混淆本地仓库与上游仓库的同步关系，导致提交冲突或无法合并。下面梳理一套标准的操作流程，确保你的变更能顺利进入目标分支。
核心逻辑
简单来说，你需要保证自己的仓库与原始项目保持同步，然后将修改推送到个人分支，最后发起合并请求。这中间最关键的一步是同步上游仓库，避免因为原项目更新而导致的冲突。
具体操作步骤
1. 配置远程仓库地址
如果你已经 Fork 了项目，本地通常只有 origin（指向你的仓库）。为了获取原作者的最新更新，需要添加 upstream 远程地址。
git remote add upstream https://github.com/原作者/原项目.git
验证一下是否添加成功：
git remote -v
# 输出应包含 origin 和 upstream
2. 拉取并合并上游最新代码
不要直接 push，先把手头的代码与上游主干对齐。这一步是为了减少后续 PR 时的冲突概率。
git fetch upstream
git checkout main # 切换到你的本地主分支
git merge upstream/main
如果有冲突，Git 会提示你解决。解决后提交即可。
3. 推送更改到个人分支
将你的功能分支推送到 GitHub 上的个人仓库。注意分支名要与你在网页上创建 PR 时选择的分支一致。
git checkout feature-branch
git push origin feature-branch
4. 发起 Pull Request
登录 GitHub，进入你的仓库页面。系统通常会提示你有新分支可比较。点击 Compare & pull request，填写标题和描述，确认无误后提交。
常用术语速查
界面操作中常遇到一些英文词汇，理解它们有助于准确操作：
- Comment: 评论，用于讨论代码细节。
- Confirm: 确认，通常指确认合并操作。
- Merge: 合并，将源分支代码合入目标分支。
- Verified: 已证实，表示提交签名验证通过。
- Pull Request: 拉动请求，即我们常说的 PR。
- Compare changes across branches: 比较不同分支、提交或标签间的更改。
- Branch, tag, commit, or history marker: 分支、标记、提交或历史记录标记。
注意事项
- 保持分支整洁：每次 PR 尽量只针对一个功能点，避免大杂烩式提交。
- 及时响应 Review：发起 PR 后，留意他人的评论并及时修改代码。
- 同步上游：如果 PR 长时间未合并，记得再次执行
fetch和merge操作，防止因上游变动导致无法自动合并。
掌握这套流程后，无论是参与开源还是团队协作，代码流转都会更加顺畅。
