如果拉取请求未合并并且上游/主服务器前进，则应该是理想的git工作流程

Question

我想了解在开源项目中提出针对新功能更改的提取请求的理想git工作流程。我有这种情况（其中M是原始上游项目，而我在M2分叉了该项目）。我开始使用该功能并添加了提交：

M1 --- M2 --- M3
       |
       M2 --- F1 --- F2

现在我的功能已经准备就绪，我在M3上重新建立了功能分支并提交了“拉取请求”。因此，此时，我的功能分支变为：

M1 --- M2 --- M3 --- F1 --- F2

我将以上内容推送给了我的主人，并提交了请求请求。但是我的这个公关没有被合并。我的公关在那里呆了几天，而这次师傅又进步了。

M1 --- M2 --- M3 --- M4 --- M5

现在，项目所有者在查看我的更改后要求我提交具有最新更改的新PR。因此，在这种状态下，如果我再次在功能分支检出的情况下在上游/主服务器上进行了重新部署，我会不会遇到这种情况？ ：

(M1 --- M2 --- M3 --- M4 --- M5) --- (M1 --- M2 --- M3 --- F1 --- F2)

1）我的思维方法是否正确理解了git工作流程？ 2）在这种情况下可以遵循的更好或最佳做法是什么？

如果这是最愚蠢的问题，请原谅我，因为我才刚刚开始学习git，但仍不学习大多数内容。谢谢！

Answer 1

您可以重新设置基准。 git中的分支只是指向提交的指针，因此您的情况基本上与您首次重新定位之前的情况完全相同。

请记住，您的方案当前如下所示：

  M1 --- M2 --- M3 --- M4 --- M5
                |
                M3 --- F1 --- F2

与您以前拥有的非常相似。在主服务器上重新建立基础将导致：

M1 --- M2 --- M3 --- M4 --- M5 --- F1 --- F2