为什么Fork GitHub仓库后需要在新建分支上进行修改？

• 保证默认分支始终可以和上游仓库干净同步：你Fork出来的仓库的默认分支，本质是上游仓库默认分支的一个快照。如果你直接在默认分支上改代码，后续上游仓库有新版本更新的时候，你拉取同步代码很容易出现大量冲突，也很难把你的个人改动和上游的更新内容彻底分开。如果所有改动都放在独立的新建分支，默认分支可以一直保持和上游完全同步，随时能拉取最新的上游代码，完全不会被自己的改动干扰。
• 支持同时并行多个独立的开发任务：如果你同时要给上游提交两个完全不相关的修改——比如一个是修复登录页的bug，一个是加个新的导出功能，各自放在独立分支开发的话，两个改动完全不会互相掺杂。提交PR的时候可以分别提，上游维护者可以独立审核、合并，不会出现一个改动没改完，另一个也没法提交的情况。
• 降低操作失误的影响范围：如果直接在默认分支改代码，要是改崩了想回滚，很容易误删有用的内容，甚至搞乱整个仓库的提交历史。用独立分支开发的话，就算改到完全没法用的程度，直接删掉这个分支，重新从干净的默认分支拉一个新分支开发就行，完全不会影响其他分支的内容。
• 适配上游仓库的PR提交规范：绝大多数开源仓库都要求提交的PR是基于最新默认分支的干净提交线，你在独立分支开发的话，提交PR前可以很方便地把你的分支rebase到上游最新的默认分支上，去掉多余的合并提交，保证提交历史清晰，方便上游维护者合并你的改动。

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