为什么我需要fork一个repo，而不是在原来的repo中创建一个分支来通过PR引入变化？

Question

这个问题是关于 Github工作流程 与fork一个版本库。我不太清楚为什么要分叉一个版本库。

我有以下内容 使用案例: 我想为一个开源项目做贡献。

我在Pluralsight上看了很多关于Github的视频。一些开发者使用以下工作流程。

1. 他们分叉一个仓库
2. 将分叉后的仓库克隆到本地。
3. 在本地主分支中进行修改。
4. 将修改推送到原主分支（从克隆的repo）。
5. 然后打开一个PR，将原源repo master（被分叉的那个）的改动合并到上游repo master（原始的那个）。

我什么我会做的流动。

1. 克隆上游的repo（原始的）在本地进行克隆
2. 创建一个功能分支
3. 在功能分支中进行修改
4. 将功能分支推送到上游repo中。
5. 做一个PR，把我的特性分支合并到上游主分支。

在我看来，在这种情况下，分叉repo增加了额外的复杂性，因为我个人发现使用一个repo比使用两个repo更简单。我看不出我描述的用例有什么好处。谁能解释一下我错过了什么？

谢谢你

Answer 1

4. 将功能分支推送到上游版本库中

这就是你的想法的问题所在。随机的人没有权限将自己的分支推送到官方上游repo。