git merge等效于git rebase --onto

问题描述

我发现自己正在执行以下工作流程：

• 从我们的foo（“ master”）分支创建功能分支（“ develop”）
• 工作，工作，工作...
• 提交对foo的拉取请求
• 在等待批准时，开始进行相关功能...：
• 从我先前的bar分支中创建另一个功能分支（“ foo”
• ...因为工作是如此紧密，以至于我无法直接从develop开始工作，而且我等不及要评论了-他们有时需要一周以上的时间
• 提交对bar的拉取请求
• 获得foo的批准，并将其合并到develop
• [我们使用壁球合并]
• 人们正在审核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中有多个提交，那么即使此过程也可以是PITA。我通常会在最后将foo合并到bar中，因此它们之间绝对没有冲突。但是，bar中的早期提交与最新的foo之间可能存在冲突。因此，我必须在git rebase -i bar上进行一次bar并将其压缩为一次提交，然后再进行git rebase --onto develop foo……对于保存历史记录来说不是很好……因为现在我要压缩out评论提交，等等。所以有时候我会用另一种选择：

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

又脏又臭-所有评论提交历史都丢失了...

解决方法

这可以按预期工作，但是它重写了历史，并且因为人们已经在查看酒吧而感到不满意，并且无法真正知道我强行按下时我做了什么。

GitHub显然会将PR页面中引用的先前提交标记为过时，但是您是正确的：在强制推入{{1}之前，检测您在基于develop的基础上必须进行的更改很麻烦。 }。

我会考虑将其推为“ bar”，并参考原始的bar2 PR从bar2进行新的PR。
这样一来，审阅者就可以compare those two PR branches并迅速确定在以下之间是否有重大变化：

• 已获批准的原始bar公关
• 新的bar PR，必须将其重新开发为基础，以促进其PR合并的发展。

,

这就是我的目的...

git merge -X ours develop

然后由于git有时在合并冲突时对其提供的选项不太聪明，因此我用以下方法验证了结果：

diff <(git diff Foo origin/Bar) <(git diff develop Bar)

幸运的是，我没有修剪过（很少这样做）。如果有更好的方法，我仍然愿意接受其他答案-暂时不要回答。

如果有一个解决方案可以保留Bar的历史记录，不显示Foo的提交历史记录（像git rebase --onto一样，并且不需要任何干预，在将各个提交重播到Bar时将它们合并到develop中。但是我考虑得越多，我不确定在理论上是否可行。因此，我认为我可以忍受Foo的历史记录中显示的Bar中的无关紧要的提交。以上满足所有其他要求。

编辑：还没有机会尝试，但是我认为这就是rerere的目的。