git merge 相当于 git rebase --onto

Question

我发现自己遇到了执行以下操作的工作流程:

• 从我们的develop(“master”)分支创建一个功能分支(“foo”)
• 工作，工作，工作...
• 为 foo 提交 pull 请求
• 在等待批准的同时，开始研究相关功能...:
• 从我之前的 foo 分支创建另一个功能分支(“bar”)
• ...因为工作联系紧密，我无法直接从 develop 取得进展 + 我迫不及待地等待评论——他们有时需要一个多星期
• 为 bar 提交 pull 请求
• 获得 foo 的批准并将其 merge 到 develop
• [我们使用压缩 merge ]
• 人们正在审查 bar，有评论，也许 bar 现在已经通过了
• 现在我将 bar rebase 如下:
• git checkout 栏
• git rebase --onto develop foo
• git push --force origin bar
• 如果目前尚未获得批准，则获得 bar 的批准，并将其 merge 到 develop

这按预期工作，但它重写了历史，并且不受欢迎，因为人们已经在查看 bar，并且没有办法真正知道我在强制 push 时做了什么.

如果我尝试在不进行 rebase 的情况下进行 merge ，我会遇到各种 merge 冲突。这就像 develop 试图“撤消”我在 bar 中所做的更改。

我的问题是:

是否有与 git rebase --onto 等效的 git merge 工作流？？？像这样的东西:

• git checkout 栏
• git merge ???开发 ？？？富

是否有一些技巧，例如...也许我将 foo merge 回 bar，或者设置上游的一些技巧？我在这里钓鱼...

谢谢!

编辑:另一件事...如果我在 bar 中有多个提交，即使这个过程也可以是 PITA。我通常会在最后将 foo merge 到 bar 中，所以它们之间肯定没有冲突。但是 bar 中的早期提交和最新的 foo 之间可能存在冲突。所以我必须在 bar 上执行 git rebase -i bar 并将其压缩为一次提交，然后再执行 git rebase --onto develop foo...不利于保存历史...因为现在我正在压缩评论提交等。所以有时我会使用另一种选择:

• git checkout 栏
• git reset foo
• git 添加内容
• git commit -m "One commit of foo-bar delta"

同样，肮脏的——所有的评论提交历史都丢失了……

Answer 1

This works as expected, but it re-writes history, and is frowned upon because people have already been looking at bar, and there's no way to really know what I did when I force-pushed.

GitHub 会清楚地将 PR 页面中引用的先前提交标记为已过时，但你是对的:在强制推送 栏。

我会考虑将其推送为“bar2”，并从 bar2 中引用原始 bar 进行新的 PR公关。
这将允许审稿人 compare those two PR branches并快速确定之间是否有任何重大变化:

• 原始bar PR，已获批
• 新的 bar2 PR，必须重新基于 develop 以促进其 PR merge 以进行开发。