GitHub PR规范咨询：个人Fork仓库应基于新分支还是Master提交PR？

朋友，这问题问得很关键——行业通用的最优实践绝对是：创建独立的功能分支来开发，永远别直接在你fork仓库的主分支（比如master/main）上做修改。下面给你掰扯清楚为啥，以及正确的操作流程：

为啥不能直接动主分支？ #

• 同步上游仓库会变麻烦：如果你一直在自己的主分支改代码，等上游仓库更新后，你要同步代码时大概率会遇到冲突，得花额外时间解决冲突才能继续开发；而主分支保持干净的话，你随时可以拉取上游的最新代码，完全没冲突烦恼。
• 多任务并行彻底没辙：要是之后你同时要开发两个功能，直接改主分支的话，两个功能的代码会混在一起，没法分开提交PR，审核也会变得混乱；用独立分支的话，每个功能一个分支，互不干扰，想提哪个PR就提哪个。
• PR内容更聚焦，审核更顺畅：每个分支对应一个具体的功能或修复，PR里的修改都是围绕这个目标的，审核者一眼就能看懂你的改动逻辑，也方便后续追溯代码历史。

正确的操作流程 #

1. 先同步你的主分支与上游仓库：

   # 先添加上游仓库的远程地址（第一次操作的话）
   git remote add upstream <上游仓库的URL>
   # 切换到主分支
   git checkout main
   # 拉取上游的最新代码
   git pull upstream main
   # 把同步后的代码推送到自己的fork仓库
   git push origin main
   

2. 基于最新主分支创建功能分支：

   # 分支名建议用清晰的命名，比如feature/新增用户导出功能
   git checkout -b feature/your-new-feature-name
   

3. 在这个分支上完成所有开发、测试：放心改，所有修改都只在这个分支里，不会影响主分支。
4. 提交并推送分支到自己的fork：

   git add .
   git commit -m "feat: 实现XX新功能，完成相关测试"
   git push origin feature/your-new-feature-name
   

5. 发起PR：去上游仓库的PR页面，选择你的fork仓库里的这个功能分支作为源，上游的主分支作为目标提交即可。

哪怕你现在只开发一个功能，也建议这么做——毕竟你的主分支保持干净同步的话，后续再开发新功能时，直接从主分支切新分支就行，完全不用纠结历史修改的问题。

内容的提问来源于stack exchange，提问作者Joe