上一次 git 合并后的 git rebase

git rebase after previous git merge

提问by INS

I have the following situation:

我有以下情况：

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

• 我clone从主存储库（X）创建了一个（Y），因为有很多人在研究 Y 我们没有做任何事情rebase，只有merges。当我们想要将 ( push) Y交付给 X 时，我们想要做一个rebase让事情变得漂亮和干净

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

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

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

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

回答by Jon Lemmon

git merge --squashis now my preferred way of rebasing after a large amount of work and many merges (see this answer). If the branch you're working on is called my-branchand you want to rebase from masterthen just do the following:

git merge --squash现在是我在大量工作和多次合并后首选的变基方式（请参阅此答案）。如果您正在处理的分支被调用，my-branch并且您想从那里变基，master那么只需执行以下操作：

git checkout my-branch
git branch -m my-branch-old
git checkout master
git checkout -b my-branch
git merge --squash my-branch-old
git commit

回答by Karl Bielefeldt

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 exactlythe same as the one you tested during development. That also solves your issue about the previously solved merge conflicts.

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

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 devto update your working tree to match the devbranch. Then you can commit everything into one big commit and merge it into master as normal.

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

回答by VonC

Two remarks:

两点说明：

• you can rebase your own (non yet pushed) work as many time as you want on top of newly fetched commits.
• You could avoid the merge conflicts (during rebase) if you had activated git rerere, which is done for this kind of situation.
  See more at git rerere.

• 您可以在新获取的提交之上根据需要多次重新设置您自己的（尚未推送的）工作。
• 如果您已激活git rerere，则可以避免合并冲突（在变基期间），这是针对这种情况完成的。
  见更多git rerere。

回答by dbaston

You can take all of the changes in your branch and put them into a new commit in masterwith the following:

您可以使用分支中的所有更改并将它们放入新的提交中master，如下所示：

git diff master > my_branch.patch
git checkout master
patch -p1 < my_branch.patch

Then stage your files and commit.

然后暂存您的文件并提交。

回答by Ajax

Regarding the replay of merge conflicts, you can use git rerere to maintain a database of how merge conflicts have already been solved, so that performing a rebase that results in the same conflicts will have the laborious parts done for you automatically.

关于合并冲突的重放，您可以使用 git rerere 来维护一个关于如何解决合并冲突的数据库，以便执行导致相同冲突的 rebase 将自动为您完成繁重的部分。

https://hackernoon.com/fix-conflicts-only-once-with-git-rerere-7d116b2cec67

https://hackernoon.com/fix-conflicts-only-once-with-git-rerere-7d116b2cec67

git config --global rerere.enabled true

git config --global rerere.enabled true

The one thing to look out for is that if you resolved something incorrectlyit will be automatically borked for you next time too, and you may not really realize it.

需要注意的一件事是，如果您解决了错误的问题，下次也会自动为您解决问题，而您可能没有真正意识到这一点。

More formal documentation here: https://git-scm.com/docs/git-rerere

更正式的文档在这里：https: //git-scm.com/docs/git-rerere