Question

在处理项目时，我们在分支之间进行更改时弄乱了同步。最初有一个功能分支foo，此分支重新建立了对master的支持，但是，本地master并未同步，因此当移至新分支bar时，前一个分支的所有提交都将被添加到新分支。 git树看起来像这样：

Master =>  A--B--C--D--E--Merge
               \-C--D--E-/-F--G--H   <= Bar
                  Foo

我的目标是彻底删除foo，因为它已经重新掌握了基础，并且具有类似以下内容：

Master =>  A--B--C--D--E
                        \-F--G--H    <=Bar

编辑：

因此，这似乎比我教的还要混乱。另外，我不是很精通git，甚至无法得出确切的结论。我将尽我所能地详细介绍。

我和队友正在研究一个项目。为了实现一项功能，我们创建了一个单独的分支foo。

A -- B <-- (master)
      \
       C -- D -- E <-- (foo)

完成此功能后，我将foo重新定为master。现在这棵树看起来像这样：

A -- B -- C -- D -- E <-- (master)

需要实现新功能，因此打开了新分支bar。

A -- B -- C -- D -- E <-- (master)
                     \
                      F -- G -- H <-- (bar)

这一切都是我的目的。现在，队友推送了他的代码，我想他没有同步某些分支，并且还存在一些需要合并的冲突，但是最后，git树看起来像这样：

A -- B -- C -- D -- E <-- (master)
      \             | \
       C -- D -------- M1 ------ M2 -- I <-- (bar)
                    \           /
                     F -- G -- H

位置：

M1说：将master合并到foo
M2说：将bar合并到foo
I是新队友的承诺

此外，我对M2中的消息感到有些困惑，因为这意味着我们最后只剩下foo，而我们的树只有bar。

我确实按照@Mark Adelsberger的建议运行了git rebase master bar，但是我在提交C时立即遇到合并冲突，并且中止了重新设置基准。按照答案，它应该自动确定这两个C是相同的提交，并跳过它们，但这不是事实。

我的目标是在可能的情况下将树弄平，这意味着在C分支中摆脱D和bar，并希望合并或放置F，{{ 1}}和G与H，M1和M2在同一行。

回到问题，我发现我的第一篇文章缺少很多细节。希望此编辑可以阐明我面临的问题。

Answer 1

因此，尽管@Mark Adelsberger的答案不能完全解决问题，但确实向我展示了研究方向。

做一个简单的git rebase master bar并没有做，因为我在提交C时立即遇到了冲突。因为提交是重复的，所以应该没有发生这种情况，并且应该跳过。

但是，进行git rebase -i master bar确实有帮助，因为我可以手动排除提交C和D。最重要的是，它还摆脱了M1和M2的局面，使之成为一个干净利落的日志。

从先前的git分支中删除预先提交的提交

1 个答案: