如何解决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
的目的。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。