9

After working for several weeks with a half dozen different branches and merges, on both my laptop and work and my desktop at home, my history has gotten a bit convoluted. For example, I just did a fetch, then merged master with origin/master. Now, when I do git show-branches, the output looks like this:

! [login] Changed domain name.
 ! [master] Merge remote branch 'origin/master'
  ! [migrate-1.9] Migrating to 1.9.1 on Heroku
   ! [rebase-master] Merge remote branch 'origin/master'
----
 - - [master] Merge remote branch 'origin/master'
 + + [master^2] A bit of re-arranging and cleanup.
 - - [master^2^] Merge branch 'rpx-login'
 + + [master^2^^2] Commented out some debug logging.
 + + [master^2^^2^] Monkey-patched Rack::Request#ip
 + + [master^2^^2~2] dump each request to log
....

I would like to clean this up with a git rebase. I created a new branch, rebase-master, for this purpose, and on this branch tried git rebase <common-ancestor>. However, I have to resolve many conflicts, and the end result on branch rebase-master no longer matches the corresponding version on master, which has already been tested and works!

I thought I saw a solution to this somewhere but can't find it anymore. Does anyone know how to do this? Or will these convoluted ref names go away when I start deleting un-needed branches that I have already merged with?

I am the sole developer on this project, so there is no one else who will be affected.

1
  • 9
    ;-) Philosophical note: History gets convoluted. That's fact of life. Get over it. Commented Jun 25, 2010 at 17:25

2 Answers 2

14

The best way to clean up a convoluted history is to keep the history linear. You do that by avoiding any kind of merge other than fast-forward.

The work flow goes like this.

$ git checkout -b foobranch
<do stuff>
$ git commit
<do stuff>
$ git commit
...

When it's time to integrate the branch into master, don't merge it. Instead, rebase this branch against the master. That will make the branch no longer look like a branch, but but simply more growth on the top of the tree. You resolve any merge conflicts during the rebase.

$ git fetch origin
$ git rebase origin/master

Now, merge the branch into master. This will be a fast-forward merge.

$ git checkout master
$ git merge foobranch

And now push the work upstream.

$ git push
6

The normal process, for repos where you can force push a branch (replacing the remote history by a new one created locally by a rebase), is to do:

git rebase --interactive

But again, that is only valid if you are the only one pulling from your repos, and even then you will have to reinitialize some of your local branches to the new remote tracking ones that have been rewritten.

From rebase session, you can trimming Git commits and squash history, in order to get the kind of history you need.

2
  • See also stackoverflow.com/questions/2719579/…
    – VonC
    Commented Jun 11, 2010 at 21:37
  • umm... it's plenty valid without pulling from remote. you can easily rebase -i <commit-ish> (or basically pretty much anything) local branch, remote branch, commit. Commented Jul 12, 2010 at 4:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.