Nobody:

Me: here's how I use git (thread): the commits in my projects are almost never a reflection of actual history. Instead, before pushing to upstream (and sometimes after!) I collapse all my wips, bug fixes, etc. so my commits are mostly each stable, self-contained features

I also prefer to rebase all changes rather than merge so that the history is linear and contains no merge commits.

Why do this? Well I don't see git history as a record of "how did we get here" so much as "when was this introduced"?

The former may be of interest to future historians browsing the repo, and certainly I'm depriving people of the joy of seeing my fuckups, but the main strength of clean, linear git history is that it greatly simplifies the process of bisecting and reverting changes.

git bisect (if you're not familiar with it) is a handy tools that automates the process of identifying the commit where a bug was introduced. It does this by performing a binary search through the history, which takes log(n) steps instead of the n steps needed for a naive search.

Once you've found the buggy commit, if your history Is clean enough you can often simply revert that commit to fix it. If the commit was within the current release cycle, I'll often just excise it from history and then reapply it on top of the other commits so I can fix it.

I didn't always work this way. When I first started with git all I knew was stage, commit & push, and making changes to history sounded like an arcane thing that you'd only do under extreme circumstances (Prior to git I'd been using svn where that sort of shenanigans doesn't fly)

After a while I learned about --amend and force push which let you overwrite your last commit. Super handy for making "wip" commits, or when you fuck up your travis.yml config 17 times in a row and don't want the world to know your shame.

Later I learned about pull --rebase as an alternative to merge, which gets rid of those nasty merge commits.

Next was reset --keep, which lets you undo your last few messy commits and then reapply the changes in a more organized fashion.

And finally I learned interactive rebase

So I must be a real whiz with the command-line right?

Absolutely not. I have no idea of the syntax for half the commands I just mentioned. I even had to look a couple up for this tweet thread.

I use Git Tower which makes most of these things a simple drag and drop operation.

Anyway, all this is why I'm a little suspicious of people who say git is "easy" and try to shame GUI users.

Maybe those people do all these things too and are Just That Good™, but I'd bet that at least in some cases they've only scratched the surface of what git can actually do