如果拉取请求未合并且上游/主要进展，那么理想的git工作流应该是什么

Question

我想了解在开源项目的情况下什么是理想的git工作流，其中提交拉取请求以进行新的功能更改。我有这个场景（其中M是最初的上游项目，我将项目分配到M2）。我开始研究该功能并添加了提交：

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

现在我的功能已准备就绪，我在M3顶部重新设置了功能分支并提交了一个Pull Request。所以此时，我的功能分支变为：

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

我将上面的内容推送给了我的主人并提交了一份Pull Request。但我的这个公关没有合并。我的PR已经存在了几天，而且这个时候主人已经进步了。

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