CODEWITHSUNDEEP
gitversion-control
Learn OpenGL ES
Learn OpenGL ES

Reputation: 4960

How can I convert a long series of git merges into a single rebase without merge conflicts?

So I have a branch of master, let's call it foo, that I've been using for a while, and after about 50 commits or so I was getting a rather complicated merge history, as foo had some subbranches of its own. The history was not important to me here, so I decided to clean things up by rebasing each branch and squashing all the commits down to one, so that I'd have just one commit representing the difference between master and that branch.

At first I thought I could just do:

git checkout foo
git rebase master

but this didn't work out for me. The branch had over 50 commits, each touching many files, and each commit was getting a bunch of conflicts.

Instead, what I ended up doing was this:

git checkout foo
<copy all files to another folder>
git checkout master
git branch -D foo
git checkout -b foo
<overwrite all files with the copy I made earlier, and create a new commit>

This served my needs of turning the long history of merges into a single squashed rebase without dealing with all the conflicts along the way, but I'm just wondering if there was a more "git-friendly" way of doing this?

Upvotes: 3

Views: 956

Answers (3)

Stuart P. Bentley
Stuart P. Bentley

Reputation: 10755

Git's porcelain can't really handle the contortions necessary to truly squash all the merge steps into one octopus merge commit. Luckily, Git exposes the plumbing required so that you can do this with one command. See this answer to a question I had about octopus merges.

Upvotes: 0

Abizern
Abizern

Reputation: 150785

Have you tried:

git merge --squash

What this does is it takes all the changes and puts them into the index ready to be committed. You'll still have merge conflicts, but they will be in one place and you can fix them before commiting the stated in one big chunk.

For a more detailed explanation and diagrams have a look at this

Upvotes: 0

Adam Dymitruk
Adam Dymitruk

Reputation: 129782

The friendlier way of doing this in git is to make a 3rd integration branch. As you develop foo, merge master and foo on that. This will show git how you are dealing with the code bases changing at the same time. It is important to have rerere (reuse recorded resolution) enabled in your config.

Now when you are finally ready to merge foo into master, git will know how to resolve the conflicts as you were telling it how to do that all along.

Or, just merge that integration branch into master when ready. You should have no conflicts. It depends if you can tolerate all those test merges in your history.

This is somewhat related to my post on Branch per Feature: http://dymitruk.com/blog/2012/02/05/branch-per-feature/

I don't recommend squashing commits as you lose information on how files came to be in the state that they are in. The more information that git has to work with, the better.

Upvotes: 3

Related Questions