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 anyrebase
but onlymerge
s. When we want to deliver(push
) Y to X we would like to do arebase
in order to have things nice and clean
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.
You can take all of the changes in your branch and put them into a new commit in
master
with the following:Then stage your files and commit.
Two remarks:
git rerere
, which is done for this kind of situation.See more at
git rerere
.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 calledmy-branch
and you want to rebase frommaster
then just do the following: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 thedev
branch. Then you can commit everything into one big commit and merge it into master as normal.