堆叠的分支和 PR 由于合并被压扁而产生冲突

Question

我在开发 main 时使用堆叠分支 <- feature1 <- feature2 ..., as well as stacked PRs with feature2 PR'd against feature1 and so on. My company uses squash merge when going into main i.e. in GitHub (actually GitLab) when you merge your PR it squashes all the commits into one and merges that. So when I try to merge main back into feature2 it's a total mess of conflicts because feature2 has e.g. 5 commits from feature1 but main has only 1 commit with all the same changes.

在网上搜索之后，我发现有一种非常麻烦的几乎无法使用的方法来处理这个问题，使用 rebase 和移动分支头等。还有一个名为 update-refs 的新功能，它可以“处理”一些混乱的情况为你。

我的问题是，1）是否没有其他方法可以更自动或更不那么痛苦地处理这种情况。 2）如果 rebase --update-refs 是唯一的方法，有人可以列出一些可以促进这一点的命令。以下是一些问题：

1. 是否有一个命令可以清楚地表明哪些分支相互堆叠，哪个是顶部，哪个是底部，以及我贡献的并且可能需要向下移动的提交。
2. 如果功能 1 和功能 2 之间存在冲突，我如何避免解决功能 1 和功能 5 之间每次提交的冲突
3. 有没有一种方法可以以编程方式沿着分支链向上查找最上游分支和最下游分支，这样我就可以说“git checkoutmost downStreamBranch; git rebase --update-refsmostDownStreamBranch;
4. 如果有人在做这个例程，你能详细分享一下你的例程吗？

如果这个问题看起来很熟悉，那是因为我几天前刚刚问过这个问题，他们关闭了它，说这是一个关于如何合并分支的非常基本的问题的欺骗。我无法重新打开它，所以我再试一次。

Answer 1

我的公司使用南瓜合并

是的。好吧，如果你不想发生这些冲突，就不要这样做。这是一个非常糟糕的政策。您所描述的是它不好的主要原因之一：如果一个分支（或一个分支及其子分支）寿命很长，因此被多次合并，那么合并冲突实际上是不可避免的。 （如果你不明白为什么，请阅读我的https://www.biteinteractive.com/understanding-git-merge/。）

因此，您需要停止创建堆叠分支，或者说服您的“公司”使用real合并。