1
我们分叉了一个Github项目并对其进行了更改。对于每项任务，我创建一个单独的分支，然后我将它合并到叉子中的master。将分叉推送为多个拉取请求
所以现在我有一个master工作，就像原始回购中的master之前的20个提交。
该项目的规则是create pull request for each task。
虽然，我知道怎么做git，但我不确定这个过程。
我不确定的是我如何创建第二个提交中的任务1的拉取请求，然后是第五个提交中的任务2等。
我犯了一个错误，现在只能同时为多个修复创建拉取请求吗？
我是不是应该做这样的：
修复任务
上叉
创建叉主拉请求，原来的主用主控合并吗？
编辑
@OliverCharlesworth你的建议是我在过去的工作方式，但它带来了许多问题。由于我首先解决了一些任务，然后为每个任务创建PR，但它与主人创建了很多冲突（徒劳）。所以每次我创建PR时，我都会收到一条消息，说它不能自动合并，但我必须先解决冲突。然后，对于90％的PR，我必须处理合并，并且仅在合并时损失几个小时。
这就是我认为我做错了的原因。
所以当我切换到规则“修复1任务，然后合并为主人”，我避免了所有这些愚蠢的冲突，并保存我们的合并。
既然你说“从分公司做公关”是正确的路要走，如何避免愚蠢的冲突并且不会在愚蠢的合并过程中失去几个小时？
注意：当我说“愚蠢”时，这意味着所有的冲突都会回到相同的代码片段中去。当我遵循新规则时，永远不会发生的事情。傻乎乎的意思是“没有很好的理由就会失去合并时间”。
如果您将更改推送到您的主分支（这是一个分支），您在上游回购中所做的pull请求将更新并显示您主分支中的所有提交。 AFAIK没有办法避免这种情况，除非你为每个任务创建一个额外的分支并承诺这一点，并为它们制作一个PR。 – CoDEmanX
解决方案是不合并到您的叉子上的主。从分支中创建一个PR回原始的回购。 –
@OliverCharlesworth请检查编辑。评论太长了。 – sandalone