压缩的PR在我的堆叠分支中引起了严重的冲突。

huangapple go评论65阅读模式
英文:

squashed prs are causing major conflicts in my stacked branches

问题

以下是要翻译的内容:

在我工作时,我创建了一个分支(branch1),然后创建了一个PR(pr1),然后继续在该分支1中的代码上进行工作。我从我的分支(branch1)创建了一个分支(branch2)。然后,基于pr1,我创建了一个PR(pr2)。也许对pr1有一些反馈。所以我在branch1上创建了一个新的提交并推送到pr1。然后,我将branch1合并到branch2并更新pr2。

这似乎是一种完全自然的工作方式,事实上,我看不出还有其他合理的工作方式,除了将所有内容保留在一个分支中,然后将一个庞大的PR投给我的队友进行审查。

问题在于远程设置为将你的PR压缩合并到主分支。所以我将pr1合并到主分支。然后,主分支有一个新的提交,而branch2有x个基本上是孤立的提交。当我尝试将主分支合并到branch2时,我花了接下来的一个小时来解决冲突,希望不会撤销大量的工作。

鉴于我们正在使用压缩合并,我只能看到一些“解决方案”。

1)将p4合并到pr3,然后合并到pr2,然后合并到pr1,然后将pr1压缩合并到主分支。这很糟糕,因为你很容易失去新提交的合并位置,以及它们是否已经被审查,这可能会变得一团糟。

2)准确确定在branch2中有哪些提交不在branch1中(记住branch1仍然有许多提交,只有主分支被压缩了)。然后,我猜要在主分支上创建一个新分支,比如branch2.1,并仅将这些提交重新基于新分支。这很糟糕,因为a)我甚至还没有弄清楚如何做到这一点,b)我会失去branch2上pr2的所有上下文,因为它现在是branch2.1,c)因为即使可能存在这种可能性,我怀疑这将是一个多步骤的过程,很容易出错。

我认为要求开发人员等待PR完全审查并合并才能继续工作是不合理的。我还认为,许多人,尤其是做出这种决定的高层管理人员,喜欢压缩合并,因为这使他们能够轻松地了解存储库中发生了什么。

我已经搜索了好几天(在解决冲突之间),到目前为止还没有找到任何关于如何解决这种情况的系统或讨论。我的第一个问题是,是否已知有方法可以解决这个问题。我的第二个问题是,如果没有,我该如何制定一系列命令,可以可靠地获得正确的提交,并以某种方式将它们放在来自远程的压缩之上。

谢谢。

Stack Overflow认为这是https://stackoverflow.com/q/57392328/494150的重复,然而,这与那个问题几乎没有关系。我的问题是关于解决一个包含在上游分支中被压缩的提交的问题。

英文:

as I work I create a branch (branch1) then I create a pr (pr1), then I keep working on the feature which is based on the code in that branch1. I create a branch (branch2) off of my branch (branch1). Then I create a pr(pr2) based on pr1. Maybe there's some feed back on pr1. So I create a new commit on branch1 and push it to pr1. Then I merge branch1 into branch2 and update pr2.

This seems like a totally natural way to work, and in fact I can't see any other reasonable way to work short of keeping everything in one branch and dumping a massive pr on my teammates to review.

The problem is that the remote is setup to squash merge your pr into main. So I merge pr1 into main. Then main has 1 new commit and branch2 has x number of basically orphaned commits. When I try to merge main into branch2, I spend the next hour resolving conflicts hoping I"m not undoing tons of work.

Given the intransigent fact that we are using squash merges, I can see only a couple "solutions".

  1. merge p4, into pr3 into pr2 into pr1, then squash merge pr1 into main. This stinks because you easily loose track of where new commits are merged to, and if they have been reviewed, it can be a real mess

  2. figure out exactly which commits are in branch2 but not in branch1 ( remember branch1 is still many commits, only main has the squash ). Then, I guess create a new branch. say branch2.1 off of main and rebase only those commits onto the new branch. This stinks for because a) I haven't even figured out how to do it and b) I would then loose all the context of pr2 on branch2 because it's now branch2.1 and c) because even if it's possible I suspect it will be a many step process that could easily be messed up.

I don't think it's reasonable to ask developers to wait for a PR to be completely reviewed and merged before doing more work. I also think that lots of folks, especially higher ups who make these kind of decisions like squash merges because it make it easy for them to see what's going on in the repository.

I've been search ( in between resolving conflicts ) for several days so far and have not found any system or even discussion about how to over come this situation. My first question is, is there a known way to do this. My second question is, if not, how could I go about crafting a series of commands that will reliably get me the correct commits and some how get them on top of the squash that comes from remote.

Thanks.

SO thinks this is a duplicate of https://stackoverflow.com/q/57392328/494150 however, it has very little to do with that question. My question is about resolving an issue where a branch contains commits which have been squashed in upstream branches

答案1

得分: 1

抱歉,我只能翻译文本内容,不提供其他回应。以下是您提供的文本的翻译:

"看起来你是那个正在合并这些PR的人。这意味着你可以在你的端上模拟这个“压缩”的过程,这样你就能跟上远程操作的一切花招。(我假设是远程需要执行实际的合并,否则你就不会陷入这个困境。)

当你要合并位于堆栈中的 x,它位于 yz 之下时:

  1. git switch z(堆栈顶部)
  2. git rebase --interactive --update-refs <主分支>
    • --update-refs 需要 Git 2.38.0 或更高版本
  3. 交互式地压缩 x 上的所有提交
  4. 强制推送 x
  5. 执行合并
  6. 重新基于更新后的主分支对 z 进行变基(使用 --update-refs

(也许重新基于堆栈底部相对于更新堆栈中的所有分支也可以起作用。我不太确定。)

--update-refs 将确保堆栈中的所有分支都得到更新。这就是为什么你可以从 z 开始重新基于,然后强制推送更新后的 x,最后在主分支上重新基于 z 的原因。

大多数情况下,在更新后的主分支上重新基于 z 不会有问题,因为“压缩”提交将包含与你手动进行的压缩相同的内容。或者其他人在你之前完成了这个任务,你可能会遇到冲突,但这在任何工作流程中有时都会发生。

现在你的分支堆栈应该已经得到正确更新。"

英文:

It seems like you are the one who is merging these PRs. That means that
you can emulate this “squashing” on your end and in that way keep up
with the shenanigans that the remote is doing. (I’m assuming that it’s
the remote that has to do the actual merge or else you wouldn’t be in
this predicament.)

When you are about to merge x which is beneath y and z in the
stack:

  1. git switch z (top of the stack)
  2. git rebase --interactive --update-refs &lt;main branch&gt;
    • --update-refs requires Git 2.38.0 or higher
  3. Interactively squash all the commits on x
  4. Force push x
  5. Do the merge
  6. Rebase z (with --update-refs) onto the updated main branch

(It might also work to rebase the bottom of the stack w.r.t. updating
all the branches in the stack. I’m not sure.)

--update-refs will make sure that all the branches in your stack are
updated. That’s why you can start the rebase on z, then force-push the
updated x, and do a final rebase on z against the main branch.

Rebasing z on top of the updated main branch won’t be a problem most
of the time since the “squashed” commit will contain the same as the
squash you did manually. Or else someone else beat you to the punch and
you might get a conflict, but that happens sometimes in any workflow.

Now your stack of branches should be properly updated.

huangapple
  • 本文由 发表于 2023年5月17日 06:31:22
  • 转载请务必保留本文链接:https://go.coder-hub.com/76267475.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定