Question

为了开发功能，我创建了一个功能分支（称为feature/a）。

在feature/a的开发过程中，我发现存在一个错误，因此我基于master创建了一个错误分支（称为fix/b）。

修复此错误并提交后，我再次签出feature/a，然后运行git rebase origin/master。但是因为它取决于fix/b，所以我运行了git rebase origin/fix/b。在两次重新定基期间，我都解决了一些冲突。

然后我继续处理feature/a，在完成feature/a之后，就在我请求拉取请求之前，我意识到有很多重复的提交。为什么有很多提交重复？我认为这可能是因为我是从多种来源中改编而来的，但是我尝试在本地复制，但没有发生。

另一个问题，在这种情况下，正确的策略是什么？有人有什么想法吗？

更新＃1

抱歉，我忘了提一下，那时fix/b仍未合并回到master。因此情况如下所示：

master --> m1 --> m2
 |\
 | \
 |  feature/a --> a1 --> a2
 |
fix/b --> b1 --> b2

假设我在a2的{{1}}上，理想情况下，我希望会发生以下情况： * feature/a，该图应变为： -> m1-> m2-> a1-> a2 * git rebase master，该图应变为： -> m1-> m2-> b1-> b2-> a1-> a2

但是，在我的情况下，该图更像下图： -> m1-> m2-> b1-> b2-> m1-> m2-> b1-> b2-> a1-> a2

我无法在本地git存储库中复制。

我的问题实际上是：如果有两个分支（A和B），都没有合并到git rebase fix/b，而一个分支则依赖于另一个（master依赖于branch A ）。在这种情况下，为了继续开发branch B，我应该从branch A和master的基础上重新发展吗？

Answer 1

无论何时进行基础调整，都会在目标分支（feature/a）和（origin/master）中创建新的提交。由于origin/fix/b已经有origin/master个提交，因此从origin/fix/b进行基础迁移时，您会在目标分支feature/a中看到重复的提交。

您应该做的是，您应该将origin/master视为所有合并/重新设置的共享分支。因此，在将origin/master合并到fix/b之后，您应该刚刚将origin/master重新定位到目标分支origin/master。

如果要保留历史记录，则应进行合并。如果您想要更清晰的历史记录，请重新设定基准。无论哪种情况，您都应仅将feature/a保留为共享分支，并将origin/master从rebase/merge保留到您的分支中。在这里是origin/master。

feature/a

Answer 2

让我们看一下您的重新设置序列，因为考虑到patch id mechanism，相似的提交不应该被重新设置两次。
意思是，您不应看到m1 / m2重复两次。但是，您看到了它们。

假设我在a2上的feature/a位置，理想情况下，我希望会发生以下情况：git rebase master，图应该变成

     (master)
 m1 --> m2 --> a1' --> a2' (feature/a)
   \
     -> b1 --> b2 (fix/b)

git rebase fix/b，该图应变为：
m1 --> m2 --> b1 --> b2 --> a1 --> a2

好吧...否：您正在master上重播功能/ a（现在包括fix/b个提交，但是master仍然存在。

 m1 --> m2 (master)
   \
     -> b1 --> b2 --> m1' --> m2' --> a1'' --> a2'' (feature/a)

因此重复了m1 / m2。

通常，不应重定来自master的提交。

将fix/b与feature/a进行简单合并最好在受益于fix/b的同时快速继续开发功能/ a。

     (master)
 m1 --> m2 --> a1' --> a2' --> M (feature/a)
   \                          /
     -> b1 ----------------> b2 (fix/b)

Answer 3

我认为这个question&answer解释得很好。

基本上，在最后一步，我们应该git push --force-with-lease。如果我们执行git push，它将生成重复的提交。