> I've never considered rebasing ...

Sounds like you either don't use GIT a lot, or your team doesn't care about clean history.

With clean history, you can, for example, automate the generation of release notes. It's very helpful if you ask me.

IMO the pursuit of, or even a concept of 'clean history' is a fallacy and waste of time. It is a level of obsession which I think is just not worth it. Furthermore, a commit log is not the same thing as release notes. More often than not you need release notes for a product to be constructed in a user centric manner, describing features or changes which affect them - and that actually comes from the original requirements lists and not the minute implementation details.

IMO don't rebase, don't worry about 'clean' history. Obsessing over those is time consuming and risky. Just do your work and move on. Let your manager/lead deal with the external world.

> Obsessing over those is time consuming and risky

That's interesting, because to me, it's slopy. If someone doesn't worry about git history, it typically means they don't do pull requests, and that typically, they don't understand know how git works (i.e. how to leverage the features of git).

For me, worrying about history literally takes no extra time. I honestly don't understand the argument.

Pull requests is not the only way to collaborate in a team. git also works with other tools for review and merging can be done by other means.

Hi, Pascal here. The author.

Just to clarify this: The aim of rebasing is not a clean commit history. It enables you to make one in case you've been creating lots of work-in-progress commits with no semantic meaning, which makes it harder to work with it.

However, even if you stick to that, it's not like rebasing isn't of value anymore. You might still be interesting in squashing your commits or splitting them up or simply rebase on branch on top of another for various reason.

That said, I'd recommend to not advocate not to rebase if it's based on the assumption that it's only useful for clean commit histories.

> IMO the pursuit of, or even a concept of 'clean history' is a fallacy and waste of time. It is a level of obsession which I think is just not worth it.

While I do obsess over a git clean history (at least in my personal projects), I still mostly agree. Doing rebase instead of merge to have a cleaner history (as in git log) might not be worth it (git log --no-merges will return a similar image). But there's one feature I use constantly that relies on not having any useless commits on it: git blame. Whenever I'm asking myself why a changes was made (at least weekly), I'm looking for the commit that introduced the change. Things like "fix typo" or "add missing files" don't help. Hence, I am doing a lot of amends and interactive rebases to combine changes that belong to each other. It may take 2 more minutes, but it will make my (and my collegues') life easier in the future.

If you follow a PR heavy or PR only methodology heavy on meaningful merges with good descriptions, `git log --first-parent` can be more useful than `git log --no-merges`. It's more condensed and focused on high level features instead of the smaller baby steps that build up the high level. `git blame` also accepts `--first-parent`.

Sure that's all fair enough. I'm not advocating being sloppy either - just be pragmatic about the effort/reward.

You should!

If there's one tool I'd recommend everyone to learn it's rebasing. Especially interactive rebasing because it enables things like splitting commits apart, squashing them together and even run automated programs.

The interactive tools exist outside of rebase. You can also split commits apart as you work on them with for example `git add -i` without needing to rebase.

I've met junior developers I'd never trust to get rebase right, but interactive add was an important tool to teach them.

`git add i` is indeed powerful and lets you interactively craft your index before you create a commit. It doesn't enable you to split up an existing commit though.

Interactive hunk splitting the index maps to the mental model of "splitting the work in progress commit". That may be all a developer needs in a "rebase never" workflow.

Certainly can not disagree :)

I'm not trying to convince anyone here. By now I've sold over 230 copies and I"m getting really positive feedback. So it must be useful to someone.