给上游 pr，自己应该先 pr 到自己的 main 分支吗？

ai 是这么回答的，好像都可以：

直接合并到上游的 main 分支：

小红可以直接从 sub 子分支创建一个 Pull Request （ PR ）到上游的 main 分支。

这样做的好处是减少了不必要的中间步骤，但需要确保 sub 子分支与上游 main 分支没有冲突。
先合并到自己的 main 分支：

小红可以先将 sub 子分支合并到自己 fork 的 main 分支，然后再从自己的 main 分支创建一个 PR 到上游的 main 分支。
这样做的好处是可以在自己的仓库中先解决潜在的合并冲突，确保代码的稳定性。

无论选择哪种方法，都需要确保在合并前从上游 main 分支拉取最新的代码，以减少冲突的可能性。

我见过的几乎都是从自己的分支直接往 upstream 主分支合并，我个人也认为这应该是最佳实践之一。自己 fork 的主分支仅仅和 upstream 主分支保持同步就好，避免无谓的冲突。
比如说，你合并到自己的主分支后，这时候上游主分支又有新变化，如果和你的提交冲突了，你还得额外处理

直接 pr ，有冲突再 pull ，拉最新代码处理冲突

这种情况（上游 main 有更新） pull 后 rebase 到自己的 sub 子分支也能看到有没有冲突吧？

我偏向 rebase 到上游 main 后再合

同意 @smyle #2 的做法。
main 分支仅用来保持与上游同步，并在新功能开发时作为基础分枝。不直接往 main 分支 commit 或 merge 自己的东西。
向上游 PR 那就是自己的功能分枝 PR 到上游的 main ，在合并后更新自己 fork 的 main 。

fork 后拉完自己仓库添加上游 git remote add upstream https://github.com/xxx/xxx

后续再修复第二个 pr 以下大概步骤
git checkout master
git fetch upstream
git rebase upstream master
git checkout -b fix-xxxx
code .
git add -A
git commit -s -m 'fix xxxxx'
git push fix-xxx
大概这样