git - git merge 相当于 git rebase --onto

Question

我发现自己遇到了一个工作流程，我在其中执行以下操作：

• foo从我们的develop（“master”）分支创建一个特性分支（“ ”）
• 工作工作工作...
• 提交拉取请求foo
• 在等待批准的同时，开始研究相关功能......：
• bar从我以前的foo分支创建另一个功能分支（“ ”）
• ...因为这项工作是如此紧密地联系在一起，以至于我无法直接从develop+ 我迫不及待地等待评论——他们有时需要一个多星期的时间
• 提交拉取请求bar
• 获得批准foo并将其合并到develop
• [我们使用 squash-merges]
• 人们正在审查bar，有意见，bar甚至现在可能已经批准
• 现在我变基bar如下：
• git checkout bar
• git rebase --onto develop foo
• git push --force origin bar
• bar如果现在还没有批准，则获得批准，并将其合并到develop

这按预期工作，但它改写了历史，并且因为人们已经在看bar，所以没有办法真正知道我在强制推动时做了什么。

如果我尝试在没有变基的情况下合并，我会遇到各种合并冲突。这就像develop试图“撤消”我在bar.

我的问题是：

是否有等效的git merge工作流程git rebase --onto？？？就像是：

• git checkout bar
• git merge ??? develop ??? foo

是否有一些技巧，比如......也许我重新合并foo到bar，或者设置上游的一些技巧？我在这里钓鱼...

谢谢！

编辑：另一件事......如果我在bar. 我通常会在最后合并foo，bar所以它们之间肯定没有冲突。但是在早期提交bar和最新的foo. 所以我必须先做一个git rebase -i baronbar并将其压缩为一个提交，然后再执行git rebase --onto develop foo......对于保存历史不是很好......因为现在我正在压缩评论提交等。所以有时我会使用另一种选择：

• git checkout bar
• git reset foo
• git add stuff
• git commit -m "One commit of foo-bar delta"

再次，肮脏 - 所有评论提交历史都丢失了......

标签： gitgit-mergerebasegit-rebasemerge-conflict-resolution

Answer 1

这按预期工作，但它改写了历史，并且因为人们已经在看酒吧而皱眉，并且没有办法真正知道我在强制推动时做了什么。

developGitHub 会清楚地将 PR 页面中引用的先前提交标记为已过时，但您是对的：在强制推送之前检测您在变基期间必须进行的更改是很麻烦的bar。

我会考虑将其推为“ bar2”，并从bar2参考原始PR 进行新的barPR。
这将允许审阅者比较这两个 PR 分支并快速确定是否有任何重大变化：

• bar已获批准的原始PR
• 新的bar2PR 必须重新基于 develop 以促进其 PR 合并开发。