前一次 git 合并后的 git rebase

我有以下情况:

  • 我从一个主存储库(X)创建了一个 clone(Y) ，因为有许多人在 Y 上工作，我们没有做任何 rebase，但只有 merge。当我们想交付(push) Y 到 X，我们想做一个 rebase，以便有东西漂亮和清洁

问题是，在执行 rebase时，我们被要求执行在前面的 merge步骤中已经执行过的所有合并操作。有没有解决这个问题的办法，除了那个意味着真正重做合并的办法？

既然我们已经解决了冲突合并的问题我本以为会很简单。

60980 次浏览
小开

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.
    http://git-scm.com/images/rerere2.png See more at git rerere.
小开
最佳答案

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.

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 merge --squash is 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-branch and you want to rebase from main then just do the following:

git checkout my-branch
git branch -m my-branch-old
git checkout main
git checkout -b my-branch
git merge --squash my-branch-old
git commit
小开

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

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

Then stage your files and commit.

小开

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.

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

git config --global rerere.enabled true

The one thing to look out for is that if you resolved something incorrectly it 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


提交答案