Git rebase loses history, then why rebase?

Question

I\'ve been looking into rebasing with Git over the past couple days. Most of the arguments for rebasing say that it cleans up the history and makes it more linear. If you do

Answer 1

Organizing your history is the point of using rebase over merge, and it's extremely valuable.

What use is a git history which accurately reflects every code change of the past? Do you need such a thing for some kind of certification effort? If you don't, why do you want that? The past as it really happened is messy and difficult to understand. I mean, why not also include every character which you wrote then deleted while editing the file?

The most common way you'll use your git history is reading it. Finding which commit caused an issue and exploring the different versions of a file are probably the two most common use cases. Both these use cases become much simpler and convenient when your git history is straight (and clean!).

Perhaps even more importantly than using rebase to share changes with the rest of the team, each member should use rebase to format their changes into a logical collection of self-contained commits. Development doesn't naturally occur in logical steps that directly follow each other. Sometimes you just push a commit on your branch just because it's the end of the day and you have to go. Putting this kind of information in your git history is pure noise. I routinely squash a feature that took 20 commits down to just one or two, because there's just no point showing anything which didn't end up being part of the finished product.

Even if the development history of your feature was an unholy mess, you can and absolutely should craft an utopic git history. You get everything right the first time in the correct order, you did feature A on day 1 and feature B on day 2, there were no bugs or temporary print statements. Why should you do that? Because it's easier to understand for someone reading your changes.

If you combine this idea with git bisect then curating your master history to only contain commits which pass all the tests defined at the time becomes even more helpful. It will be trivial to find the origin point of a bug, as git bisect will just work. If you use merge and upload the entire development history of each of your branches to master, there is no chance of bisect being actually helpful.