如何使用重基而不是合并来重放历史记录以清除拉请求？
一位同事对git很陌生。他已经在某个特性分支工作了很长一段时间，并创建了一个公关现在(Azure DevOps，如果这一点重要)。
不幸的是，他没有意识到git rebase，所以他一直使用git pull origin master进行同步，这导致了相当多的合并提交。(在他的特性分支上有20个“真实”提交和9个合并提交)
现在，这将是好的，但结果是，不同的观点，PR不仅显示他的变化，而且所有其他的变化是适用于主人在同一时间。现在基本上不可能进行适当的代码检查，因为他的更改与其他所有更改都是无法区分的。
现在，我的计划是以某种方式重播他的所有更改，但是每当他进行合并时，我都会做一个重基操作。无论何时在重基过程中发生冲突，混合相应的合并提交的更改都应该完美地解决这个问题(理论上)。大多数合并都是相当困难的，所以不能手动重做，因为这项工作已经完成了。
实现这一目标的最佳方法是什么？
- I尝试了
git rebase master，但这不包括合并提交，因此它们必须手动完成。 - I也尝试了
git rebase --preserve-merges master，但由于某些原因，这只会在最近的合并提交之前执行重基操作(见下文)。
如果没有更好的选择，我将不得不做20+9樱桃.
在图片中，情况是：
A---B---C- ... --D---E---F master
\ \ ... \
G---m---H- ... --m---I---J feature我想要这个：
A---B---C- ... --D---E---F master
\
G'--m'--H' ... --m'--I'--J' feature选项1将只给我这个选项，但我希望获得ms (不一定是提交的，但我希望以某种方式解决这些冲突)：
A---B---C- ... --D---E---F master
\
G'------H' ... ------I'--J' feature备选案文2只会给我这方面的帮助，但没有多大帮助：
A---B---C- ... --D---E---F master
\ \ ... \ \
G---m---H- ... --m-------m'--I'--J' feature回答 2
Stack Overflow用户
发布于 2019-11-21 11:50:10
我找到了一个非常顺利的解决方案：
- 使自己完全处于他开始功能工作时的状态。
git签出了-b replay_feature
- ，在完成合并之前，他重新做了他所做的事情：
现在，他做了
- ，他做了
git merge master，而我做了git rebase master：
git rebase #当时，B是
- 大师的负责人，现在我正处于重新基地的过程中，面临着与
m完全相同的冲突。因此，为了像他那样解决这个问题，我只是检查他合并提交中的所有冲突文件。
git签出--文件在冲突中。all #为所有冲突做这件事#确保所有的东西都编译git添加。git重基--继续
- 重复步骤4.直到重基完成
重复步骤2至5，直到他的全部工作被重放，用重基地取代所有合并，并应用他的冲突解决方案。最后，比较了replay_feature分支和feature分支。如果一切顺利，所有的文件都应该是相同的。
git diff replay_feature feature # should not show anythingStack Overflow用户
发布于 2019-11-20 18:18:06
重基地不能这么做。它要么完全放弃合并，要么重新执行合并。如果它重新执行合并，则您得到的合并提交是实际的合并提交。在你的情况下，你想要与-m类似的摘樱桃。(我认为您需要-m 1，但请确保，特别是在使用以下内容之前。)
，如果没有更好的选择，我将不得不做20+9樱桃.
这就是该走的路。使用git rev-list或类似的方法列出要复制的所有提交。把它们中的哪一种标记下来。然后写一个小脚本-让：
git cherry-pick <hash-of-G>
git cherry-pick -m 1 <hash-of-merge#1> # or maybe -m 2?
git cherry-pick <hash-of-H>诸若此类。一次只运行一个命令，这样您就知道如果一个命令失败了，或者如果您对处理错误有足够的把握，那么就以-e set脚本的形式运行它，这样樱桃选择失败就可以停止其余的选择了。
https://stackoverflow.com/questions/58960159
复制相似问题
腾讯云开发者
