上一次 git 合并后的 git rebase [英] git rebase after previous git merge

问题描述

我有以下情况:

• 我从主存储库 (X) 创建了一个 clone(Y)，因为有很多人在 Y 上工作，我们没有做任何 rebase 而只是 <代码>合并s.当我们想要将 (push) Y 传递到 X 时，我们想要做一个 rebase 以使事情变得漂亮和干净

• I created a clone(Y) from a main repository(X), because there were many people working on Y we didn't do any rebase but only merges. When we want to deliver(push) Y to X we would like to do a rebase in order to have things nice and clean

问题在于，在执行 rebase 时，我们被要求执行我们在前面的 merge 步骤中已经完成的所有合并.除了意味着实际重新进行合并的解决方案之外，是否有解决方案?

The problem is that when doing rebase we are asked to do all the merges that we already did in the previous merge steps. Is there a solution to this, beside the one that means actually re-doing the merges?

我希望它非常简单，因为我们已经解决了冲突的合并.

I expected it to be pretty straightforward since we already solved the conflicting merges.

推荐答案

为获得干净"的历史记录而重新定位被高估了.如果您想保留历史记录，最好的方法就是进行合并而不是变基.这样，如果您需要返回修订版，它完全与您在开发过程中测试的版本相同.这也解决了您之前解决的合并冲突的问题.

Rebasing to get a "clean" history is overrated. The best way if you want to preserve history is just to do the merge instead of a rebase. That way if you ever need to go back to a revision, it is exactly the same as the one you tested during development. That also solves your issue about the previously solved merge conflicts.

如果你不关心保存历史，你可以从 master 创建一个新分支，检查它，然后执行 git read-tree -u -m dev 来更新你的工作树以匹配 dev 分支.然后，您可以将所有内容提交到一个大提交中，然后照常将其合并到 master 中.

If you don't care about preserving history, you can create a new branch off of master, check it out, then do a git read-tree -u -m dev to update your working tree to match the dev branch. Then you can commit everything into one big commit and merge it into master as normal.

这篇关于上一次 git 合并后的 git rebase的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！