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?
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.